PSA: New Promise-based IndexedDB.jsm module

Ehsan Akhgari ehsan.akhgari at gmail.com
Sun Mar 26 19:29:19 UTC 2017


On Sun, Mar 26, 2017 at 3:17 PM, Kris Maglione <kmaglione at mozilla.com>
wrote:

> On Sun, Mar 26, 2017 at 11:03:38AM +0200, Dão Gottwald wrote:
>
>> For those who are curious like me, it looks like extension meta data is
>> our
>> first and so far only consumer of this:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1344590
>>
>> Kris, what lead you to wanting to use IndexedDB here? What are the
>> tradeoffs compared to mozstorage or plain JSON (see sessionstore)?
>>
>
> Two main reasons:
>
> 1) The normalized data we store needs to contain non-JSON types like Maps.
> IndexedDB supports this.
>
> 2) Parsing JSON was one of the most expensive things we were doing on the
> main thread during startup. Deserializing structured clone data from
> IndexedDB has proven to be much faster.


Also JSON isn't incrementally readable and updatable, so it's really not
that suitable of a format for storing any data that can be large which
lends itself to incremental reading and writing (for example, session
restore data.)  As Kris mentioned, parsing it is expensive, and so is
deserializing it, and because the format dictates that you always have to
write more than what you need to, it's inherently inefficient.  It was
arguably the wrong choice for session restore data but that horse has left
the barn.  It's great to have more lower level storage primitives.  The way
that I think about it, for a web browser, JSON is an unsuitable storage
format for any data which has a size controllable by web pages from a
performance perspective (as in, there is _no_ efficient way to use JSON for
storing such data.)

(For whatever it's worth, I have been analyzing a ton of performance issues
lately, and I have seen a super recurring theme of abstractions that are a
bit too high level being used to solve a problem and therefore tying our
hands in really bad and sometimes funny situations.  We all know that
abstractions have a cost, but most people think of the cost in terms of
something simple like CPU time for a function running, but often times the
cost of abstractions is more along the ways of dictating the way you design
your software by making it work in ways that is inherently less efficient.
So having lower level abstractions sometimes gives you better tools to
solve problems in ways that don't end up hurting us way down the line, but
it may not always be super easy to come up with examples of how things can
go wrong before they happen...)

Cheers,
-- 
Ehsan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170326/7f1db32c/attachment.html>


More information about the firefox-dev mailing list