Tối ưu hóa để có CRDT nhanh hơn

• Bài viết giải thích quá trình tìm ra và khắc phục các vấn đề của những thư viện CRDT hiện có để làm chúng nhanh hơn

→ Benchmark thử nghiệm: nhập 180 nghìn ký tự, xóa 70 nghìn ký tự, di chuyển con trỏ 100 nghìn lần

→ Nhanh hơn 5000x so với Automerge (5 phút so với 56ms)

• Vì sao Automerge chậm?

→ Khi tài liệu càng lớn, cấu trúc dữ liệu nội bộ dựa trên cây càng phình to và chậm đi

→ Dùng ImmutableJS rất nhiều; tính năng tốt nhưng chậm và tốn nhiều bộ nhớ

→ Mỗi ký tự được nhập vào đều được xử lý như một item riêng biệt

→ Hiện Automerge đang triển khai riêng một phiên bản Rust đã được cải thiện hiệu năng

• Thư viện Yjs nhanh hơn Automerge rất nhiều

→ Đã cải thiện cấu trúc dữ liệu

• Diamond Types: một triển khai CRDT dựa trên Rust

→ Chuyển ngôn ngữ sang Rust và cải thiện cấu trúc dữ liệu như Yjs để làm nó nhanh hơn

→ Dùng Range Tree thay cho linked list

→ Khi chạy bằng Wasm, nhanh hơn 3 lần so với thao tác thay đổi chuỗi trong JS (0.19s, nhanh hơn Automerge 1500 lần)

→ Khi chạy native trên Rust, đạt 0.056s, nhanh hơn 5000 lần

Phụ lục A - Nếu phải dùng CRDT trong ứng dụng của tôi thì nên chọn gì?

• Nếu làm công cụ cộng tác dựa trên tài liệu thì "khuyến nghị Yjs". Hiệu năng tốt, dùng ít bộ nhớ và sẽ còn nhanh hơn nữa

• Tất nhiên Automerge cũng rất xuất sắc. Có lẽ năm nay sẽ còn nhanh hơn

• Diamond thực sự rất nhanh, nhưng vẫn còn cần bổ sung nhiều tính năng

• Nếu muốn ngữ nghĩa kiểu DB hơn là ngữ nghĩa tài liệu, thì dù dựa trên OT vẫn khuyến nghị ShareDB

• Đang kỳ vọng vào Redwood

[xguru]

Bài viết này là bài mới nhất của Joseph Gentle, nhà phát triển Google Wave và cũng là tác giả của bài viết dưới đây. Bạn nên đọc trước bài đó.

• Tôi đã sai. CRDT là tương lai. https://vi.news.hada.io/topic?id=2962

[alstjr7375]

Bài viết của Raph Levien, nhà phát triển của Xi Editor, cũng đáng để tham khảo.

https://github.com/xi-editor/xi-editor/…