Re: Structured clone in WebStorage

On Sat, Dec 4, 2010 at 1:23 AM, João Eiras <joao.eiras@gmail.com> wrote:

> On , Darin Fisher <darin@chromium.org> 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.

J