In IndexedDB docs , it is recommended to use a cursor in order to step through all the values in the object store. In Bug 1486980 we figured out that doing so was extremely slow. I isolated the usage of the high-level lib  that we use in RemoteSettings in order to observe the phenomena: https://codepen.io/anon/pen/QZaRBe Iterating on less than 1000 entries using a cursor takes around 1 second on my Firefox. It is globally 7 times faster in Chromium (Note: other IDB operations are faster too but out of scope here). Some explanation was given by :asuth in https://bugzilla.mozilla.org/show_bug.cgi?id=1486980#c32 tldr: Bug 1168606 could help and switching to getAll() might be the workaround for some use-cases. Having a bug that tracks this precise performance deficiency can help. Especially now that more and more browser features rely on IndexedDB we could face this core issue indirectly. It might also be a good idea to be more insisting about `getAll()` in the docs, as well as mentioning its downsides regarding I/O, its usage with the `count` parameter etc.  https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Using_a_cursor  https://github.com/Kinto/kinto.js/blob/master/src/adapters/IDB.js
As I understand it, bug 1168606 will fix this, right? If so, I'll qf- this, since we're tagging bug 1168606 with a qf priority.
Whiteboard: [qf] → [qf-]
Just double-checking on my understanding of the relationships here with asuth.
Yes, bug 1168606 will fix this.
You need to log in before you can comment on or make changes to this bug.