4 ms·
CRDTs are not inherently “crazy slow”. Researchers just don’t succumb to the appeal of premature optimization. See: https://josephg.com/blog/crdts-go-brrr/ htt
by jason_oster 1y ago
CRDTs are not inherently “crazy slow”. Researchers just don’t succumb to the appeal of premature optimization.
See: https://josephg.com/blog/crdts-go-brrr/ https://josephg.com/blog/crdts-go-brrr/
(And even these optimizations are nascent. It can still get so much better.)
The section you quoted describes an effect of homomorphic encryption alone.
There is the problem that both CRDTs and encryption add some overhead, and the overhead is additive when use together. But I can’t tell if that is the point you are trying to make.
- hansvm 1y ago> additive The overhead is usually multiplicative per-item. Let's say you're doing N things. CRDTs make that O(Nk) for some scaling factor k, and adding encryption makes it O(Nkj) for some scaling factor j. Give or take some multiplicative log (or worse) factors depending on the implementation.
- josephg 1y agoYep. Author here - that article is out of date now. I should really do a followup. Performance of CRDTs has improved again through a new grab bag of tricks. I’ve also been told the beta of automerge 3 uses a lot of the optimisations in that post, and it’s now much faster as a result. A crdt library should be able to handle millions of changes per second. If it’s the bottleneck, something somewhere has gone wrong.
- PartiallyTyped 1y agoThe article was a great read, many thanks! Looking forward to the next!
- anty 1y agoPlease do! There are too few current articles about CRDTs around!