HTML localStorage setItem и производительность getItem около 5 МБ лимита?
Я создавал небольшой проект, который использовал HTML localStorage. Хотя я нигде не был близок к пределу 5 МБ для localStorage, я решил сделать стресс-тест в любом случае.
По сути, я загрузил объекты данных в один объект LocalStorage, пока он не был чуть ниже этого предела, и должен запросить установку и получение различных элементов.
Затем я приурочил выполнение setItem и getItem неофициально с использованием объекта Date javascript и обработчиков событий (привязанные get и set to buttons в HTML и просто нажал = P)
Производительность была ужасающей, с запросами от 600 мс до 5000 мс, а использование памяти приближалось к 200 МБ в более тяжелых случаях. Это было в Google Chrome с одним расширением (Google Speed Tracer) на MacOSX.
В Safari это в основном > 4000 м. все время.
Firefox был неожиданностью, почти ничего не превышал 150 мс.
Все это было сделано в основном бездействующим состоянием - нет возможности YouTube (Flash), а не много вкладок (ничего, кроме Gmail), и без каких-либо приложений, кроме фонового процесса + Браузер. Как только возникла проблема с интенсивной памятью, localStorage также замедлилась. FWIW, я работаю в конце 2008 года Mac → 2.0Ghz Duo Core с 2 ГБ оперативной памяти DDR3.
===
Итак, вопросы:
- Кто-нибудь выполнил сравнительные тесты против localStorage и установил для разных разных значений ключа и значения и в разных браузерах?
- Я предполагаю, что большая разница в латентности и использовании памяти между Firefox, а остальное - проблема Gecko vs Webkit. Я знаю, что ответ можно найти, погрузившись в эти базы кода, но я определенно хотел бы узнать, сможет ли кто-нибудь еще объяснить соответствующие подробности о реализации localStorage на этих двух машинах, чтобы объяснить огромную разницу в эффективности и латентности в браузерах?
К сожалению, я сомневаюсь, что мы сможем решить его, но чем ближе можно получить, тем меньше понимание ограничений браузера в его текущем состоянии.
Спасибо!
Ответы
Ответ 1
Браузер и версия становятся основной проблемой здесь. Дело в том, что, хотя есть так называемые браузеры на основе Webkit, они добавляют свои собственные исправления. Иногда они попадают в основной репозиторий Webkit, иногда они этого не делают. Что касается версий, браузеры всегда двигают цели, поэтому этот тест может быть совершенно иным, если вы используете бета-версию или ночную сборку.
Тогда есть общий прецедент. Если ваш прецедент не является нормой, проблемы будут не такими очевидными, и это менее вероятно, чтобы их заметили и обратились. Даже если есть исправления, у поставщиков браузеров есть много проблем для решения, поэтому есть шанс, что он настроен для другой сборки (опять же, ночные сборки могут давать разные результаты).
Честно говоря, лучший способ действий состоял в том, чтобы обсудить эти результаты в соответствующем списке/форуме рассылки браузера, если он еще не был рассмотрен. Люди будут с большей вероятностью проводить тестирование и видеть, соответствуют ли результаты.
