evoluhq / evolu

A local-first platform designed for privacy, ease of use, and no vendor lock-in
https://evolu.dev
MIT License
1.29k stars 44 forks source link

Optimizations #3

Open steida opened 1 year ago

steida commented 1 year ago

Another idea is to hold the clock, Merkle tree, and table definitions in tab memory to skip reads, but it's unfortunately impossible because inactive tabs would have to be updated in the background, and such an async operation can't be reliable, AFAIK. We can already do that because we have one DB instance per many tabs.

For m:n relations, consider https://github.com/ccorcos/tuple-database#Motivation as an additional abstraction. SQL has to be always supported because that's what people use and know. The core idea of a tuple database is to build indexes by queries; I think Evolu can do that, too, because it does not expose mutation SQLite API.

IMHO unnecessary

steida commented 6 months ago

My goal is to have CRDT that is fast but not black box. Evolu prefers simplicity. Everyone should be able to read the code and understand how it works. I watch what other developers do, and I want to learn from their mistakes. The current implementation could be better, but it works well. And we will improve it. There are several hyper-optimized CRDT... black boxes. Rust makes code inaccessible, and it's not a good trade-off. JavaScript is fast enough and will be even faster with Static Hermes.

steida commented 6 months ago

As for Kysely. Let's wait https://github.com/kysely-org/kysely/pull/218#issuecomment-1304519259

steida commented 3 months ago

Consider replacing Merkle Trie with Range-Based Set Reconciliation

steida commented 3 months ago

Use optimizations similar to Automerge and Negentropy to save bandwidth