Re: [IndexedDB] Closing on bug 9903 (collations)

On Fri, May 6, 2011 at 2:32 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> I'm not worried about crashes or security issues, but I am worried
> about performance. Not only is it the overhead of crossing from C++
> into JS, but also the fact that the C++ code has to go through extra
> pains to ensure that the world around it still makes sense by the time
> you come back from the JS callback. For example the callback could
> have deleted all IndexedDB databases and navigated to a new page. So
> every time you get back from JS you have to spend a bunch of time
> rechecking all the state that you were holding in your function
> implementation.

I think that a stored procedure could be considered as a compiled
version of a serialized function. i.e. something which loses its scope
chain, and which loses access to its parent object. If it loses access
to its scope chain which includes the interesting globals, it will no
longer have access to fun things like DOM objects, roughly like
DOMWorkers but with even less exciting objects available. I'd hope
that a jit should be able to do a fairly reasonable job of optimizing
such a function given these constraints.

The resulting keys could be stored with the database, so you don't
have to recalculate them while sorting, only during insertion or if
the sort key function is changed.

> All of this is totally doable. It's not even particularly hard. But it
> costs performance.

Received on Friday, 6 May 2011 14:07:54 UTC