Safari-реализация indexeddb очень медленная

Question

Недавно Apple добавила поддержку индексированногоdb как в iOS8 Safari, так и в Safari 7.1 на OSX. Я пытаюсь использовать это в веб-приложении, которое хранит около 65 000 записей в indexeddb и запрашивает их с использованием некоторых составных индексов.

Это работает для меня, но по сравнению с внедрением Chrome indexeddb, это действительно очень медленно.

Конкретно ... запрос, который занимает 2 мс от индекса indexeddb от Chrome, занимает 500 мс против индексированного индекса Apple. Этот конкретный запрос использует составной индекс indexeddb (2 поля в ключе), используя значение IDBKeyRange.only для ключа, чтобы вернуть около 100 документов общей суммы 65 000.

Мое приложение поддерживает websql как механизм хранения, а также, когда я переключаюсь на него в Safari, производительность отличная. Мой запрос возвращается через несколько мс, как и в Chrome.

У кого-либо еще есть проблемы с медленностью реализации индекса indeddb от Apple? Любые предложения относительно того, как заставить его работать лучше или нам просто нужно ждать, пока Apple его исправит?

Я считаю, что реализация indexeddb от Apple на самом деле является только оболочкой поверх websql, и тот факт, что я могу реализовать свое приложение с использованием websql напрямую с хорошей производительностью, подразумевает, что такая оболочка, если она будет реализована, должна работать нормально. К сожалению, это еще не так!

Answer 1

Мы видели то же самое. Процесс, который вставляет 10000 объектов, занимает около 5-6 секунд для завершения Android и 15 минут для завершения на iOS8.

Safari является WebKit-браузер, так что если он использует один и тот же код, что это:

https://github.com/WebKit/webkit/blob/master/Source/WebKit2/DatabaseProcess/IndexedDB

затем IndexedDB это (плохо) на основе базы данных SQLLite.

Answer 2

У меня также был этот выпуск. Но я также обнаружил, что он становится медленнее, чем больше стол. Мне нужно было сохранить около 30 000 записей, полученных в части около 2000 с сервера и затем вставленных. Каждая вставка пакета становилась медленнее, чем предыдущая, до тех пор, пока ей не потребовалось более 80 минут для вставки. Решение, с которым мы столкнулись (и это ужасно уродливо), заключается в создании отдельного хранилища объектов для каждой части синхронизации. Затем вам нужно иметь дело с запросами на нескольких объектах/etc. но он сделал это так, чтобы он был полезен.

До тех пор, пока не будет реализована их реализация indexeddb apple get, это было лучшее решение, которое у меня есть.