Reputation: 615
I have a scenario where initial use of a web application may require ~2K records to be downloaded and stored in an IndexedDB for offline usage. In my testing, performance seems quick once all the records are loaded and indexed. However, there is a period where it's obviously indexing and unresponsive during that time. That is understandable, however is there a way to find out if the IndexedDB "is indexing" or something to that extent? I can't seem to find anything in IndexedDB documentation. Something like this would provide a better user experience if they are aware of that.
Upvotes: 1
Views: 320
Reputation: 151
having same issue here. only using chrome. no idea about other browsers.
was fine, till i started creating indexes. then slows to a crawl. easy repeat when i clear indexeddb via developer tools -> application tab. and refresh page.
on my side, i need to add some "promise" logic in to get more "async" logic going on vs straight sync. and in that break up each "store" creation / "index" creation / initial adding data to the various stores into there own promise logic. i want to say www.promisesjs.com might be worth reading.
i am trying to stay away from various packaged scripts. but some of them have some nicer "bulkadd" vs just "add" with statements of increase performance when using the "bulkadd" feature of theirs. pouchdb, localforge, db.js, dexie.js, backbone?, bookshelf? are some packaged scripts that come to mind. BEFORE WARNED: some of the packaged scripts have there own promise like logic built into them. and there maybe issues if you do or do not use the built in promise logic.
to note: sql on other databases going to come to a crawl with sudden large hit of adding or dumping data, indexeddb is no different. once you get past that initial "install lag" for lack of better phrase. everything should run smooth. or less your app itself is cpu intensive. now that i think about it, most sql like databases, with data dump / export and/or import had timeout scripts built into them. due to amount of time it might take on large database tables.
Upvotes: 1
Reputation: 8337
There's indeed nothing in the spec about being able to observe indexing; it's intended to happen behind the scenes, and be observable only when complete (e.g. if the transaction commits or aborts due to a key constraint error in existing data). If you notice particular browsers becoming unresponsive when a new index is being created you should file bugs against the browser(s).
In Chrome, at least, the createIndex() call should be "instant", and behind the scenes the index is populated asynchronously by walking over the values in the object store to compute the index entries. That happens in the same process and thread where the createIndex() call is made and so will compete with other activity on the same thread (e.g. you could see animations slow down if we don't prioritize the work appropriately).
Upvotes: 4
Reputation: 815
Are you using synchronous or asynchronous API? If async, it probably shouldn't freeze the browser. Maybe you can add a timeout event, say output something every 100ms. If it is get executed much longer than 100ms, then your browser might be busy working on the indexing.
Upvotes: 1