4 ms·
I don’t think you should be expecting a local in-memory db to require batching for reasonable performance; the main reason it’s a problem for normal DB’s is the
by setr 5y ago
I don’t think you should be expecting a local in-memory db to require batching for reasonable performance; the main reason it’s a problem for normal DB’s is the network — you’re constantly waiting for the roundtrip.
Which you obviously still have for an in-memory DB, but you should expect it to require a lot more picked low-hanging fruit before that becomes your bottleneck.
- couchand 5y agoSibling already pointed it out, but it's worth clarifying: IndexedDB is most definitely NOT and in-memory database.
- sieabahlpark 5y agoIndexedDB isn't an in memory DB?
- vlovich123 5y agoEach transaction typically has a non trivial amount of overhead as committing it requires you to verify that there wasn’t a conflict. Why would you expect that you wouldn’t need to do this just because it’s an in-memory database? You might still be modifying it concurrently through multiple tabs open to the same site modifying the same DB or because you are interleaving “concurrent” actions for some reason within a page. Has nothing to do with I/O to my knowledge. Try this experiment out with any transactional in-memory tables on any database and they should all show some amount of degradation (although maybe not necessarily quite as severe as IndexDB - 10k inserted rows/s seems below what SQLite should be putting out).
- stingraycharles 5y agoI am fairly certain that the reason you want to batch writes in a normal database is not because of RTT latency, but rather transaction overhead; e.g. indexes have to be updated only once, rather than thousands of times. Disks have to be flushed only once, etc. I am fairly certain the issues are similar for IndexedDB.