4 ms·
That's because leveldb by default writes asynchronously. And probably at the time of reading they were still in RAM/cached.
by halayli 11y ago
That's because leveldb by default writes asynchronously. And probably at the time of reading they were still in RAM/cached.
- maxpert 11y agoLet me quote LevelDB docs here: "By default, each write to leveldb is asynchronous: it returns after pushing the write from the process into the operating system. The transfer from operating system memory to the underlying persistent storage happens asynchronously. The sync flag can be turned on for a particular write to make the write operation not return until the data being written has been pushed all the way to persistent storage. (On Posix systems, this is implemented by calling either fsync(...) or fdatasync(...) or msync(..., MS_SYNC) before the write operation returns.)" and if you see my benchmarks I am flushing each entry to the disk.
- halayli 11y agoSomething is still missing. It's hard to imagine such drastic performance difference in btree implementation. btw I've had better experience using kyoto db than levelDB.