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

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
>