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: Florian Bösch <pyalot@gmail.com>
Date: Mon, 12 Nov 2012 23:59:05 +0100
Message-ID: <CAOK8ODhSZjNNJ=O4ZxedboPTFvPSC_0kZFyjVCJNuXETSzLpAQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Webapps WG <public-webapps@w3.org>
A-ha. Filled payload with random. Now it's FF 4.4s put, 5.5s get. In line
with chromes perf.


On Mon, Nov 12, 2012 at 11:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 11/12/12 1:56 PM, Florian Bösch wrote:
>
>> In FF 16.0.2 on linux, 50mb put takes about 100ms and get takes about
>> 500ms.
>>
>
> For what it's worth, I did some measuring, and the main performance cost
> centers for the write (the CPU-intensive ones, not the disk access) seem to
> be:
>
> 1)  Making a copy of the data to put in the database (because the database
> write happens on a background thread and we want to return control to JS
> before we do that to avoid blocking the main thread, so have to copy the
> data).
>
> 2)  Compressing the data (we store it compressed on disk).
>
> For the read it's decompressing and then copying out of the resulting data
> structure into the JS engine's heap for the typed array.
>
> It might be possible to mitigate the copying costs, especially if
> indexeddb had a way to indicate that things should be transferred, not
> copied, similar to postMessage.
>
> -Boris
>
Received on Monday, 12 November 2012 22:59:40 GMT

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