Re: [w3c/IndexedDB] Why is IndexedDB this bad? (Issue #369)

Since cursors return a single value at a time, and returning values is an asynchronous operation, the performance will be lower than getAll() to fetch multiple values. But getAll() may hit memory limits. Some browser engines (e.g. Chrome) optimize cursor operations, pre-fetching multiple results to avoid cross-process hops, but IndexedDB still requires a turn of the event loop to deliver each result.

_"Other way would be to use the ID and get IDs in range but then it would still need a cursor, so it's a dead end."_ - I'm not sure what you mean here. If getAll() works for you to get all records within a key range, great - use it. Constructing indexes is the usual way to avoid unnecessary iteration. 

_"why isn't the cursor written in low level like C"_ - you're welcome to inspect the implementation of the current browser engines (Chromium, Gecko, WebKit). You'll find they do all implement IndexedDB in C++ at the moment.

Questions about how to use IndexedDB efficiently probably belong on StackOverflow rather than this repo (hence, leaving this issue closed)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/369#issuecomment-998376717
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/369/998376717@github.com>