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

On Wed, May 4, 2011 at 1:24 PM, Keean Schupke <keean@fry-it.com> wrote:
>
>
> On 4 May 2011 21:01, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Wed, May 4, 2011 at 1:10 AM, Keean Schupke <keean@fry-it.com> wrote:
>> > On 4 May 2011 00:57, Jonas Sicking <jonas@sicking.cc> wrote:
>> >>
>> >> On Tue, May 3, 2011 at 12:19 AM, Keean Schupke <keean@fry-it.com>
>> >> wrote:
>> >> > The more I think about it, the more I want a user-specified
>> >> > comparison
>> >> > function. Efficiency should not be an issue here - the engines should
>> >> > tweek
>> >> > the JIT compiler to fix any efficiency issues. Just let the user pass
>> >> > a
>> >> > closure (remember functions are first-class in JavaScript so this is
>> >> > not
>> >> > a
>> >> > callback nor an event).
>> >>
>> >> I don't think we should do callbacks for the first version of
>> >> javascript. It gets very messy since we can't rely on that the script
>> >> function will be returning stable values.
>> >
>> > garbage in = garbage out. The programmers job is to write a correct
>> > comparison function. All functions have this problem. By this argument
>> > we
>> > had all better give up programming because there is a risk we may write
>> > a
>> > function that returns incorrect results.
>>
>> Browsers can certainly deal with this, and ensure that the only one
>> suffering is the author of the buggy algorithm. However this comes at
>> a cost in that the browser sorting algorithm can't go into infinite
>> loops or crash even in the face of the most ridiculous comparison
>> algorithm. In other words, the browser will likely have to use a
>> slower sorting implementation in order to be robust.
>>
>> Additionally, there is a significant cost involved in transitioning
>> between the C++ code implementing the sorting algorithm, and the
>> javascript implemented callback. That is on top of the cost of
>> implementing the comparison function in javascript. Even in the best
>> JITs, there is a significant overhead to both these parts.
>>
>> So rather than repeating myself, i'll just quote myself:
>>
>> >> So the choice here really is between only supporting some form of
>> >> binary sorting, or supporting a built-in set of collations. Anything
>> >> else will have to wait for version 2 in my opinion.
>>
>> :)
>>
>> / Jonas
>
> I gave my answer, and some follow up questions in a previous email, so I am
> not avoiding the question. My point was any event handler (onMouseDown?)
> could have an infinite loop - why so fussy about this one function when so
> many others have the same problem?
> The performance point of calling to JavaScript is a valid one, but is this a
> problem? Perhaps it is fast enough. I have seen no evidence that is will be
> too slow for people to use - perhaps the bottle neck will be the disk/flash
> access speed for fetching the blocks and not the JavaScript comparison
> function.

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.

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

/ Jonas

Received on Thursday, 5 May 2011 23:33:34 UTC