Kevin Jahns
Local First Meetup 2024
> Optimizing CRDTs
Back in 2018..
"Real Differences between OT and CRDT for
co-editors" by Chengzheng Sun et al.
- Questioning performance and memory usage of CRDTS.
- This was posted on every Hacker News post about CRDTs.
Today
- Yjs (CRDT) is the most used framework
- Yjs: 740k downloads / week on npm
- ShareDB: 7k downloads / week on npm
CRDT Benchmarks 2020
CRDT Benchmarks 2024
Everything tradeoff
- Seph implemented a CRDTs that is 5000x faster than existing ones!
- Only measures one characteristic (character insertion time)
⇒ Choose the right data structures to achieve the best tradeoffs
- The limiting factor of JavaScript for Yjs is the lack of control over the garbage-collector.
Using Rust/WASM tradeoffs
Pros
- Custom data structures! ⇒ More Control ⇒ Faster
Conns
- Less inspectable
- Large WASM binary size (10x larger than the Yjs bundle)
- Bundling tools are bad at handling WASM. They encode the WASM binary as a base64 string into the JavaScript Bundle
Base64 Encoding
Encodes a binary to a ASCII string
[104, 105] ↦ "aGk="
- >=33% overhead!
- Worse compression because of bit shifting
- Slow decoding in the browser
Considering that Rust binaries tend to be quite huge...
My own base64 encoder
- In WAST (WebAssebly Text Format)
- Using SIMD!
- https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format
Is WAST the future for Yjs?
WebAssebly/GC has landed everywhere:
- WASM can interact with Objects from JavaScript-land
- JavaScript-land can interact with WASM objects.
⇒ Use WAST for CRDT-specific data structures?
Pros
- Small binary size (much smaller than JavaScript)
- Manual memory management ↦ more control
Conns
- Few people speak WAST
- Still bad tooling at this time (bundler support, base64, ..)
twitter.com/kevin_jahns
