HTML localStorage setItem и производительность GetItem близка к 5 МБ?

#html #webkit #local-storage #gecko

#HTML #webkit #локальное хранилище #gecko

Вопрос:

Я создавал небольшой проект, в котором использовался HTML localStorage. Хотя я и близко не приблизился к пределу в 5 МБ для localStorage, я все равно решил провести стресс-тест.

По сути, я загружал объекты данных в один объект localStorage до тех пор, пока он немного не превысил этот предел, и должен запрашивать установку и получение различных элементов.

Затем я неофициально рассчитал время выполнения setItem и GetItem, используя объект даты javascript и обработчики событий (привязал get и set к кнопкам в HTML и просто нажал = P)

Производительность была ужасающей: запросы занимали от 600 мс до 5000 мс, а использование памяти приближалось к 200 МБ в худших случаях. Это было в Google Chrome с единственным расширением (Google Speed Tracer) на MacOSX.

В Safari это в основном > 4000 мс за все время.

Firefox был сюрпризом, в нем практически ничего не было больше 150 мс.

Все это было сделано в основном в режиме ожидания — не мешал YouTube (Flash), не было большого количества вкладок (ничего, кроме Gmail) и не было открыто никаких приложений, кроме фонового процесса браузера. Как только всплывала задача, требующая много памяти, localStorage также пропорционально замедлялся. Черт возьми, я использую Mac последней версии 2008 года с двухъядерным процессором > 2,0 ГГц и 2 ГБ оперативной памяти DDR3.

===

Итак, вопросы:

  1. Кто-нибудь проводил своего рода сравнительный анализ с localStorage get и set для различных размеров ключей и значений и в разных браузерах?
  2. Я предполагаю, что большая разница в задержке и использовании памяти между Firefox и остальными — это проблема Gecko vs Webkit. Я знаю, что ответ можно найти, углубившись в эти базы кода, но я определенно хотел бы знать, может ли кто-нибудь еще объяснить соответствующие детали о реализации localStorage на этих двух движках, чтобы объяснить огромную разницу в эффективности и задержке между браузерами?

К сожалению, я сомневаюсь, что мы сможем приступить к ее решению, но чем ближе можно подойти, так это, по крайней мере, понять ограничения браузера в его текущем состоянии.

Спасибо!

Комментарии:

1. не могли бы вы показать, какой код вы использовали? В моих нагрузочных тестах я получал гораздо более высокие скорости, чем это, но я никогда не измерял базовый размер базы данных.

Ответ №1:

Браузер и версия становятся здесь серьезной проблемой. Дело в том, что, хотя существуют так называемые браузеры на основе Webkit, они также добавляют свои собственные исправления. Иногда они попадают в основной репозиторий Webkit, иногда нет. Что касается версий, браузеры всегда являются движущимися целями, поэтому этот тест может быть совершенно другим, если вы используете бета-версию или сборку nightly.

Тогда есть общий вариант использования. Если ваш вариант использования не является нормой, проблемы не будут столь очевидны, и вероятность того, что их заметят и решат, меньше. Даже при наличии исправлений поставщикам браузеров приходится решать множество проблем, поэтому есть вероятность, что он настроен для другой сборки (опять же, ночные сборки могут давать разные результаты).

Честно говоря, лучшим вариантом действий было бы обсудить эти результаты в соответствующем списке рассылки браузера / на форуме, если это еще не было рассмотрено. Люди с большей вероятностью проведут тестирование и посмотрят, совпадают ли результаты.