Optimiser pour des CRDT plus rapides
(josephg.com)- Un article qui explique le processus consistant à identifier puis résoudre les problèmes des bibliothèques CRDT existantes afin de les rendre plus rapides
→ Benchmark de test : saisie de 180 000 caractères, suppression de 70 000 caractères, 100 000 déplacements du curseur
→ 5000x plus rapide qu'Automerge (5 minutes contre 56 ms)
- Pourquoi Automerge est-il lent ?
→ Plus le document grossit, plus sa structure de données interne basée sur des arbres grossit et ralentit
→ Il utilise beaucoup ImmutableJS : riche en fonctionnalités, mais lent et gourmand en mémoire
→ Chaque caractère saisi est traité comme un élément distinct
→ Automerge développe actuellement séparément une version Rust aux performances améliorées
- La bibliothèque Yjs est bien plus rapide qu'Automerge
→ Grâce à une amélioration de la structure de données
- Diamond Types : une implémentation de CRDT basée sur Rust
→ En changeant de langage pour Rust et en améliorant la structure de données comme Yjs, elle devient plus rapide
→ Utilise un Range Tree au lieu d'une liste chaînée
→ En exécution via Wasm, 3 fois plus rapide que la modification de chaînes en JS (0,19 s, 1500 fois plus rapide qu'Automerge)
→ En exécution Rust native, 0,056 s, soit 5000 fois plus rapide
Annexe A - Si je dois utiliser un CRDT dans mon application, que devrais-je choisir ?
-
Si vous créez un outil de collaboration centré sur les documents, « Yjs est recommandé ». Bonnes performances et faible consommation mémoire. Et il devrait encore s'accélérer
-
Bien sûr, Automerge est lui aussi excellent. Il deviendra probablement plus rapide cette année
-
Diamond est vraiment très rapide, mais il lui manque encore beaucoup de fonctionnalités
-
Si vous voulez une sémantique de base de données plutôt qu'une sémantique de document, ShareDB est recommandé, même s'il est basé sur l'OT
-
Redwood est attendu avec intérêt
2 commentaires
Ce billet est le plus récent article de Joseph Gentle, développeur de Google Wave et auteur du texte ci-dessous. Il est recommandé de le lire d’abord.
L’article de Raph Levien, le développeur de Xi Editor, mérite également d’être consulté.
https://github.com/xi-editor/xi-editor/…