Iterating store with cursor value + continue() is slow

NEW
Unassigned

Status

()

enhancement
P3
normal
7 months ago
7 months ago

People

(Reporter: leplatrem, Unassigned)

Tracking

(Depends on 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qf-])

(Reporter)

Description

7 months ago
In IndexedDB docs [0], 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 [1] 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.


[0] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Using_a_cursor

[1] https://github.com/Kinto/kinto.js/blob/master/src/adapters/IDB.js
Priority: -- → P3
Whiteboard: [qf]
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.
Flags: needinfo?(bugmail)
Yes, bug 1168606 will fix this.
Flags: needinfo?(bugmail)
You need to log in before you can comment on or make changes to this bug.