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

On Wed, May 4, 2011 at 1:10 AM, Keean Schupke <> wrote:
> On 4 May 2011 00:57, Jonas Sicking <> wrote:
>> On Tue, May 3, 2011 at 12:19 AM, Keean Schupke <> 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

Received on Wednesday, 4 May 2011 20:02:10 UTC