CODEWITHSUNDEEP
iosgoogle-chromeipadsafariindexeddb
Ivan Lytvynenko
Ivan Lytvynenko

Reputation: 21

indexedDB has bad performance on iOS?

When I read data (in my case more then 3000 items) from indexedDB it works so slow. And it doesn't matter what browser I use. I got the same results on Chrome and Safari. I used iPad 3 for testing. In scope of this issue I've found out the following interesting things:

  1. When I open my client application on the desktop version of Chrome it works in appropriate way.

  2. In case when I use WebSQL in Safari it looks fine BUT when I use indexedDB in Safari it worked SLOW.

  3. When we've used Chrome on the iPad 3 it worked SLOW too. (because, Chrome uses indexedDB)

WebSQL is deprecated and according to my investigation indexedDB has some bottlenecks on iOS (in my case iOS 9.3.5 and iPad 3). The best way for me is to find solution for Chrome(on iOS). Please write your thoughts and tips. Thanks!

Upvotes: 2

Views: 1166

Answers (1)

nbrustein
nbrustein

Reputation: 767

UPDATE: The test described below describes an issue in Safari which appears to be fixed in the 10.12.4 beta.

Here is a bit more data, but basically I'm seeing the same thing you saw. I wrote different number of records using bulkPut() to a clean IndexedDB. I did this on Chrome, Safari, and iOS 10.2 running in the XCode simulator. All three were running on the same Macbook Pro. I was using the Dexie.js wrapper, so there is some chance that this is due to the wrapper and not due to IndexedDB itself.

What I saw was that iOS and Safari both got worse per-record write times the more records I tried to write, while Chrome kept pretty much the same per-record write time regardless of the number of records I tried to write.

This table shows the records/ms in each browser.

records Chrome  Safari  ios Simulator
100     5.26    0.63    1.54
500     4.63    0.92    0.62
1000    5.26    0.71    0.61
2000    4.23    0.09    0.16
5000    4.21    0.02    0.02

Then I tried the same records using put() instead of bulkPut(). For small numbers of records, and always on Chrome, this is much slower. But for large numbers of records on either Safari browser, this is faster:

records Chrome  Safari  ios Simulator
100     0.45    0.08    0.40
500     0.46    0.14    0.35
1000    0.51    0.20    0.36
2000    0.54    0.21    0.39
5000    0.38    0.19    0.60

If this is correct (and I'm a bit skeptical that it is in all cases, since it makes no sense), then I guess the best strategy would be to use bulkPut on Chrome, but on Safari to use bulkPut in chunks of no more than 1000 records? Seems terrible. I would love to know if anyone else has more info about this or other suggestions.

Upvotes: 1

Related Questions