तेज़ CRDT के लिए ऑप्टिमाइज़ करना

• मौजूदा CRDT लाइब्रेरीज़ की समस्याएँ खोजकर उन्हें हल करते हुए उन्हें और तेज़ बनाने की प्रक्रिया समझाने वाला लेख

→ टेस्ट benchmark: 1.8 लाख अक्षरों का इनपुट, 70 हज़ार अक्षरों का deletion, 1 लाख बार cursor movement

→ Automerge की तुलना में 5000x तेज़ (5 मिनट vs. 56ms)

• Automerge धीमा क्यों है?

→ दस्तावेज़ बड़ा होने के साथ उसकी आंतरिक tree-based data structure भी बड़ी होती जाती है और धीमी पड़ती है

→ यह ImmutableJS का बहुत उपयोग करता है; फीचर अच्छे हैं, लेकिन यह धीमा है और memory usage भी ज़्यादा है

→ दर्ज किए गए हर character को अलग item के रूप में प्रोसेस करता है

→ Automerge फिलहाल performance में सुधार वाला Rust version अलग से implement कर रहा है

• Yjs लाइब्रेरी Automerge की तुलना में काफ़ी तेज़ है

→ data structure में सुधार

• Diamond Types: Rust-आधारित CRDT implementation

→ भाषा को Rust में बदलकर और Yjs की तरह data structure सुधारकर इसे और तेज़ बनाया गया

→ linked list की जगह Range Tree का उपयोग

→ Wasm में चलाने पर JS में string बदलाव से 3 गुना तेज़ (0.19s, Automerge से 1500 गुना)

→ Rust Native में चलाने पर 0.056s, यानी 5000 गुना तेज़

परिशिष्ट A - अगर मुझे अपने ऐप में CRDT इस्तेमाल करना हो, तो क्या चुनना चाहिए?

• अगर आप document-based collaboration tool बना रहे हैं, तो "Yjs की सिफारिश"। performance अच्छा है, memory usage कम है। आगे और तेज़ होने की उम्मीद है

• बेशक Automerge भी शानदार है। शायद इस साल और तेज़ हो जाएगा

• Diamond वाकई बहुत तेज़ है, लेकिन अभी इसमें कई फीचर और जोड़ने बाकी हैं

• अगर आपको document semantics की बजाय DB semantics चाहिए, तो OT-आधारित होने के बावजूद ShareDB की सिफारिश है

• Redwood का इंतज़ार है

[xguru]

यह लेख नीचे दिए गए लेख के लेखक, Google Wave डेवलपर Joseph Gentle का नवीनतम लेख है। इसे पहले पढ़ लें तो बेहतर होगा.

• मैं गलत था। CRDT ही भविष्य है। https://hi.news.hada.io/topic?id=2962

[alstjr7375]

Xi Editor के डेवलपर Raph Levien की यह पोस्ट भी देखने लायक है.

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