<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 26, 2017 at 3:17 PM, Kris Maglione <span dir="ltr"><<a href="mailto:kmaglione@mozilla.com" target="_blank">kmaglione@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Mar 26, 2017 at 11:03:38AM +0200, Dão Gottwald wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For those who are curious like me, it looks like extension meta data is our<br>
first and so far only consumer of this:<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1344590" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/s<wbr>how_bug.cgi?id=1344590</a><br>
<br>
Kris, what lead you to wanting to use IndexedDB here? What are the<br>
tradeoffs compared to mozstorage or plain JSON (see sessionstore)?<br>
</blockquote>
<br></span>
Two main reasons:<br>
<br>
1) The normalized data we store needs to contain non-JSON types like Maps. IndexedDB supports this.<br>
<br>
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.</blockquote><div><br></div><div>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.)<br></div></div><br></div><div class="gmail_extra">(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...)<br><br></div><div class="gmail_extra">Cheers,<br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Ehsan<br></div></div>
</div></div>