6 ms·
Fair skepticism — I had the same intuition going in. The SQL layer overhead alone is probably small, you're right. The bigger gain comes from a cached read cu
by swaminarayan 8mo ago
Fair skepticism — I had the same intuition going in.
The SQL layer overhead alone is probably small, you're right. The bigger
gain comes from a cached read cursor. SQLite opens and closes a cursor on
every operation. SNKV keeps one persistent cursor per column family sitting
open on the B-tree. On random deletes that means seek + delete on an already
warm cursor vs. initialize cursor + seek + delete + close on every call.
For deletes there's also prepared statement overhead in SQLite — even with
prepare/bind/step/reset, that's extra work SNKV just doesn't do.
I'd genuinely like someone else to run the numbers. Benchmark source is in
the repo if you want to poke at it — tests/test_benchmark.c on the SNKV
side and https://github.com/hash-anu/sqllite-benchmark-kv https://github.com/hash-anu/sqllite-benchmark-kv for SQLite. If your
results differ I want to know.
- Retr0id 8mo agoWhat does "column family" mean in this context?
- swaminarayan 8mo agoA named key space within the same database file — keys in "users" don't collide with keys in "sessions" but both share the same WAL and transaction.
- bflesch 8mo agoDid you measure the performance impact of having multiple trees in a single file vs. having one tree per file? I'd assume one per file is faster, is that correct?
- swaminarayan 8mo agono dont know about it. I will check it out.
- d1l 8mo agoAre you using ai for the comment replies too?!
- derwiki 8mo agoEveryone knows the emdash is a giveaway, and they are being left in
- altmanaltman 8mo agoare you reading what you're writing?
- d1l 8mo agoIt's a nonstop slop funnel as far as I can tell. Only ashamed I've been here for more than 5 minutes.
- swaminarayan 8mo agoyes