indexedDBから（私の場合は3000件以上の）データを読み込むと処理が遅くなります。そして、私が使っているブラウザは関係ありません。 ChromeとSafariで同じ結果が得られました。私はテストのためにiPad 3を使いました。この問題の範囲で 私は、次の面白いものを見つけた：私はクロームのデスクトップ版の私のクライアントアプリケーションを開くとindexedDBのパフォーマンスがiOSで悪いですか？
それが適切な方法でを動作します。場合
私はSafariでWebSQLを使用する場合、それは正常に見えるが、私はサファリでのIndexedDBを使用する場合、それはSLOWを働きました。我々はiPadの3にChromeを使用しました
はそれはあまりにもSLOWを働きました。
アップデート：以下に説明するテストでは、Safariの10.12.4ベータ版で修正されているようです。
ここにもう少しデータがありますが、基本的に私が見たのと同じことが見られます。私は、きれいなIndexedDBにbulkPut()を使って異なる数のレコードを書きました。私は、Chrome、Safari、およびXCodeシミュレータで動作するiOS 10.2でこれを行いました。 3人とも同じMacbook Proで動作していた。私はDexie.jsラッパーを使用していたので、これはラッパーに起因する可能性があり、IndexedDB自体に起因するものではありません。
私が見たのは、iOSとSafariの両方で、書き込みしようとしたレコードの数が多いほど記録ごとの書き込み時間が短くなっていますが、書き込みしようとしたレコードの数に関係なくChromeはほとんど同じ。
この表には、各ブラウザのレコード/ msが表示されます。
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
は、その後、私はput()代わりのbulkPut()を使用して同じレコードを試してみました。レコードの数が少なくても常にChromeでは、これははるかに低速です。しかし、どちらかのSafariブラウザ上の多数のレコードのために、これは高速です：
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
これが正しければ（それは意味がないので、私は、それはすべてのケースであることを少し懐疑的だ）、私はChromeでbulkPutを使用するのが最善の戦略だと思うが、bulkPutを1000レコード以下のチャンクで使用するにはSafariでどうすればよいだろうか？ひどいですね。他の誰かがこの提案や他の提案についてもっと多くの情報を持っているかどうかを知りたいです。