Optimización para lograr CRDT más rápidos

• Un artículo que explica el proceso de identificar y resolver los problemas de las bibliotecas CRDT existentes para hacerlas más rápidas

→ Benchmark de prueba: entrada de 180 mil caracteres, eliminación de 70 mil caracteres, 100 mil movimientos de cursor

→ 5000x más rápido que Automerge (5 minutos vs. 56 ms)

• ¿Por qué Automerge es lento?

→ A medida que el documento crece, la estructura de datos interna basada en árboles también crece y se vuelve más lenta

→ Usa mucho ImmutableJS; tiene buenas funciones, pero es lento y consume mucha memoria

→ Trata cada carácter ingresado como un ítem separado

→ Automerge actualmente está implementando por separado una versión en Rust con mejor rendimiento

• La biblioteca Yjs es mucho más rápida que Automerge

→ Mejora la estructura de datos

• Diamond Types: una implementación de CRDT basada en Rust

→ Cambia el lenguaje a Rust y mejora la estructura de datos como Yjs para hacerlo más rápido

→ Usa un Range Tree en lugar de una lista enlazada

→ Al ejecutarse con Wasm, es 3 veces más rápido que modificar strings en JS (0.19 s, 1500 veces más rápido que Automerge)

→ Al ejecutarse como nativo en Rust, alcanza 0.056 s, 5000 veces más rápido

Apéndice A - Si tuviera que usar CRDT en mi app, ¿cuál debería usar?

• Si vas a crear una herramienta de colaboración basada en documentos, "recomienda Yjs". Tiene buen rendimiento y bajo uso de memoria. Será aún más rápido

• Por supuesto, Automerge también es excelente. Probablemente será más rápido este año

• Diamond es realmente rápido, pero todavía necesita muchas más funciones

• Si quieres semántica de base de datos en lugar de semántica de documento, recomienda ShareDB, aunque está basado en OT

• Hay expectativas por Redwood

[xguru]

Este artículo es la publicación más reciente de Joseph Gentle, desarrollador de Google Wave y autor del texto de abajo. Vale la pena leerlo primero.

• Yo estaba equivocado. Los CRDT son el futuro. https://es.news.hada.io/topic?id=2962

[alstjr7375]

También vale la pena revisar el texto de Raph Levien, desarrollador de Xi Editor.

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