W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: Two years on and still no sensible web storage solutions exist

From: Andrew Wilson <atwilson@google.com>
Date: Mon, 12 Nov 2012 17:55:46 +0100
Message-ID: <CAArhhitSTnix5X8PH6iXhbX6_TMePet=HyZk4ytJSg8TFQ0eHQ@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Kyle Huey <me@kylehuey.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, Todd Blanchard <toddvblanchard@gmail.com>, Webapps WG <public-webapps@w3.org>
Your best bet is to report implementation/performance issues to the browser
vendors, rather than here, unless you believe that there is something
inherent in the spec that results in slow implementations.

I'd say in the specific case of Chrome, we probably have not optimized for
the case of writing out a 100MB ArrayBuffer - logging a bug at
http://crbug.com describing your use case would be a useful way to have
this addressed, at least on that platform.


On Mon, Nov 12, 2012 at 5:17 PM, Florian Bösch <pyalot@gmail.com> wrote:

> On Mon, Nov 12, 2012 at 3:49 PM, Kyle Huey <me@kylehuey.com> wrote:
>
>> Er, IndexedDB should handle ArrayBuffers just fine.  If you're seeing
>> problems with that that's an implementation bug, not a case that the spec
>> failed to handle.
>>
> You're right it does, I just checked. Nevertheless there are some issues.
>
> This testsite: http://codeflow.org/issues/indexeddb.html
> Putting 50mb takes between 2.5 to 8 seconds. Getting it between 2 to 4
> seconds.
> Putting 100mb doesn't work in Chrome at all and throws an exception on the
> put after half a second.
>
> For comparison, in python:
> Writing 50mb takes between 40-80ms. Reading takes around 50ms.
>
>
>
>
Received on Monday, 12 November 2012 16:56:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:56 GMT