Otimizações para CRDTs mais rápidos
(josephg.com)- Um texto que explica o processo de identificar e resolver os problemas das bibliotecas CRDT existentes para torná-las mais rápidas
→ Benchmark de teste: entrada de 180 mil caracteres, exclusão de 70 mil caracteres, 100 mil movimentações de cursor
→ 5000x mais rápido que o Automerge (5 minutos vs. 56ms)
- Por que o Automerge é lento?
→ À medida que o documento cresce, a estrutura de dados interna baseada em árvore cresce e fica mais lenta
→ Usa muito o ImmutableJS, que é bom em funcionalidade, mas lento e com alto uso de memória
→ Trata cada caractere digitado como um item separado
→ O Automerge atualmente está implementando separadamente uma versão em Rust com desempenho melhorado
- A biblioteca Yjs é muito mais rápida que o Automerge
→ Melhorou a estrutura de dados
- Diamond Types: uma implementação de CRDT baseada em Rust
→ Mudou a linguagem para Rust e melhorou a estrutura de dados como o Yjs para ficar mais rápido
→ Usa uma Range Tree em vez de lista ligada
→ Ao executar com Wasm, é 3x mais rápido do que alterar strings em JS (0.19s, 1500x mais rápido que o Automerge)
→ Ao executar em Rust nativo, faz 0.056s e é 5000x mais rápido
Apêndice A - Se eu for usar CRDT no meu app, qual devo escolher?
-
Se for criar uma ferramenta colaborativa baseada em documentos, "recomenda Yjs". Tem bom desempenho e baixo uso de memória. Deve ficar ainda mais rápido
-
Claro, o Automerge também é excelente. Provavelmente ficará mais rápido ainda este ano
-
O Diamond é realmente rápido, mas ainda precisa adicionar muitos recursos
-
Se você quer semântica de banco de dados em vez de semântica de documento, recomenda o ShareDB, embora seja baseado em OT
-
Expectativa pelo Redwood
2 comentários
Este artigo é o texto mais recente de Joseph Gentle, desenvolvedor do Google Wave e autor do texto abaixo. Vale a pena ler o texto anterior primeiro.
Também vale a pena consultar o texto de Raph Levien, desenvolvedor do Xi Editor.
https://github.com/xi-editor/xi-editor/…