[webkit-dev] localStorage quota limit

[Darin Fisher]

This is why LocalStorage quota should remain relatively small.  (/me holds
back urges to bitch about the LocalStorage spec.)

If people want more storage space, then DB should be used, which can more
efficiently accommodate large amounts of data.

-Darin

On Wed, Dec 2, 2009 at 10:48 AM, Jeremy Orlow <jorlow at chromium.org> wrote:

> + hixie
>
> I don't know as much about encoding types as I should.  How can you
> construct invalid UTF-16 sequences?  What does Firefox or IE do with these
> when put into LocalStorage?
>
> One thing I just considered is that our LocalStorage implementation loads
> the entire LocalStorage database for an origin into memory all at once.  It
> does this on a background thread, but it's only loaded on the first access
> to |window.localStorage| and we block on it finishing loading when you first
> try to use it.  So if |alert(window.localStorage.foo);| is the first usage
> of LocalStorage, it (and thus the main thread) will block on the whole thing
> being loaded into memory.  This can certainly be optimized, but I'm pointing
> this out because the bigger the DB is, the worse the worst case load time
> is.  (Making this better is on my todo list, but not as near the top as I'd
> like.)
>
> In case you're wondring, you can mitigate this by doing 'var storage =
> window.localStorage;' as early as possible in your script and waiting as
> long as possible to actually use window.localStorage.
>
> J
>
> On Wed, Dec 2, 2009 at 10:01 AM, Darin Adler <darin at apple.com> wrote:
>
>> On Dec 2, 2009, at 9:49 AM, Darin Fisher wrote:
>>
>> > This would probably be a performance win since it would reduce the
>> amount of disk i/o.
>> >
>> > (Note, it doesn't mean that 5 million characters could be stored since a
>> UTF-8 character might be multi-byte.)
>>
>> Currently the database can store invalid UTF-16 as well as valid UTF-16.
>> Conversion from UTF-16 to UTF-8 might not be able to preserve invalid UTF-16
>> sequences. I don’t understand how the other platforms handle this. Perhaps
>> the specification needs to be clearer on whether invalid UTF-16 is allowed.
>>
>>    -- Darin
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091202/64400163/attachment.html>