HTML localStorage setItem 和 getItem 性能接近 5MB 限制？
我正在构建一个使用 HTML localStorage 的小项目。虽然我远未达到 localStorage 的 5MB 限制，但我还是决定进行压力测试。
本质上，我将数据对象加载到单个本地存储对象中，直到它略低于该限制并且必须请求设置和获取各种项目。
然后，我使用 javascript Date 对象非正式地计时了 setItem 和 getItem 的执行事件处理程序（将 get 和 set 绑定到 HTML 中的按钮，然后单击 =P）
性能非常糟糕，请求时间在 600 毫秒到 5,000 毫秒之间，在最糟糕的情况下，内存使用量接近 200 MB。这是在 MacOSX 上的 Google Chrome 中使用单个扩展（Google Speed Tracer）。
在 Safari 中，基本上一直都是 >4,000 毫秒。
Firefox 令人惊讶，几乎没有任何超过 150 毫秒的时间。
这些基本上都是在空闲状态下完成的 - 没有 YouTube (Flash) 妨碍，没有太多选项卡（只有 Gmail），并且除了后台进程 + 浏览器之外没有打开任何应用程序。一旦出现内存密集型任务，localStorage 也会相应减慢。 FWIW，我正在运行一台 2008 年末的 Mac -> 2.0Ghz 双核，2GB DDR3 RAM。
===
所以问题是：
- 是否有人针对各种不同的键和值大小以及在不同的浏览器上针对 localStorage get 和 set 进行了某种基准测试？
- 我假设 Firefox 和其他浏览器在延迟和内存使用方面的巨大差异是 Gecko 与 Webkit 的问题。我知道可以通过深入研究这些代码库来找到答案，但我肯定想知道是否有其他人可以解释有关这两个引擎上 localStorage 实现的相关细节，以解释浏览器之间效率和延迟方面的巨大差异？
不幸的是，我怀疑我们是否能够解决这个问题，但至少可以更接近地了解浏览器在当前状态下的局限性。
谢谢！
I was building out a little project that made use of HTML localStorage. While I was nowhere close to the 5MB limit for localStorage, I decided to do a stress test anyway.
Essentially, I loaded up data objects into a single localStorage Object until it was just slightly under that limit and must requests to set and get various items.
I then timed the execution of setItem and getItem informally using the javascript Date object and event handlers (bound get and set to buttons in HTML and just clicked =P)
The performance was horrendous, with requests taking between 600ms to 5,000ms, and memory usage coming close to 200mb in the worser of the cases. This was in Google Chrome with a single extension (Google Speed Tracer), on MacOSX.
In Safari, it's basically >4,000ms all the time.
Firefox was a surprise, having pretty much nothing over 150ms.
These were all done with basically an idle state - No YouTube (Flash) getting in the way, not many tabs (nothing but Gmail), and with no applications open other than background process + the Browser. Once a memory-intensive task popped up, localStorage slowed down proportionately as well. FWIW, I'm running a late 2008 Mac -> 2.0Ghz Duo Core with 2GB DDR3 RAM.
===
So the questions:
- Has anyone done a benchmarking of sorts against localStorage get and set for various different key and value sizes, and on different browsers?
- I'm assuming the large variance in latency and memory usage between Firefox and the rest is a Gecko vs Webkit Issue. I know that the answer can be found by diving into those code bases, but I'd definitely like to know if anyone else can explain relevant details about the implementation of localStorage on these two engines to explain the massive difference in efficiency and latency across browsers?
Unfortunately, I doubt we'll be able to get to solving it, but the closer one can get is at least understanding the limitations of the browser in its current state.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
浏览器和版本成为这里的一个主要问题。问题是，虽然有所谓的“基于 Webkit”的浏览器，但它们也添加了自己的补丁。有时它们会进入主 Webkit 存储库，有时则不会。就版本而言，浏览器始终是移动目标，因此如果您使用测试版或夜间版本，此基准测试可能会完全不同。
然后是整体用例。如果您的用例不常见，问题就不会那么明显，并且不太可能引起注意和解决。即使有补丁，浏览器供应商也有很多问题需要解决，因此有可能将其设置为另一个版本（同样，夜间版本可能会产生不同的结果）。
老实说，如果尚未解决，最好的做法是在适当的浏览器邮件列表/论坛上讨论这些结果。人们将更有可能进行测试并查看结果是否匹配。
Browser and version becomes a major issue here. The thing is, while there are so-called "Webkit-Based" browsers, they add their own patches as well. Sometimes they make it into the main Webkit repository, sometimes they do not. With regards to versions, browsers are always moving targets, so this benchmark could be completely different if you use a beta or nightly build.
Then there is overall use case. If your use case is not the norm, the issues will not be as apparent, and it's less likely to get noticed and adressed. Even if there are patches, browser vendors have a lot of issues to address, so there a chance it's set for another build (again, nightly builds might produce different results).
Honestly the best course of action would to be to discuss these results on the appropriate browser mailing list / forum if it hasn't been addressed already. People will be more likely to do testing and see if the results match.