Re: Structured clone in WebStorage

On Sun, Dec 5, 2010 at 9:47 PM, Jeremy Orlow <> wrote:

> On Sat, Dec 4, 2010 at 1:23 AM, Joćo Eiras <> wrote:
>> On , Darin Fisher <> wrote:
>>  I will also add that I think WebStorage (well LocalStorage) is terrible
>>> from
>>> a performance point of view because it is synchronous, and I'd be very
>>> happy
>>> if we could discourage its usage and give people more reasons to adopt a
>>> better API like IndexedDB.
>>> -Darin
>> I don't understand how storing values in a hash map is "performant
>> terrible".
> One of the smaller performance problems with LocalStorage: You have to take
> a snapshot of that object synchronously.  Even with optimizations like copy
> on write, complex objects can take a while to make such a snapshot of.
> But the much bigger problem is that LocalStorage is shared between multiple
> windows.  To maintain run to completion, LocalStorage (and cookies) are
> specced to require taking a storage mutex (a global lock) upon first use of
> LocalStorage (or cookies) and holding it until JavaScript completes running.
>  So if two windows are both accessing LocalStorage they'll lock up each
> other and anything else running in their event loop.  IE and Chrome are the
> only two browsers with multiple event loops at the moment.  Google Chrome
> has no intention of ever implementing the storage mutex and my understanding
> is that IE is the same.
> So, to answer your question, most of the performance issue is a lock
> contention one.  And because of this, LocalStorage is (and very likely will
> always be) racy on 2 major browsers.  And as more browser adopt
> multi-process architectures, I expect they'll follow suit.

You asked only about "storing values", but note that reading values has
problems as well.  Either the browser needs to read all LocalStorage data
into memory before running any scripts in the page or it's likely that your
page will need to block on reading data from disk when it does use


Received on Sunday, 5 December 2010 21:58:32 UTC