W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Keean Schupke <keean@fry-it.com>
Date: Wed, 4 May 2011 21:24:59 +0100
Message-ID: <BANLkTimLF6eo2=y+wRPFSH9PtBm5h89n5g@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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.


Cheers,
Keean.
Received on Wednesday, 4 May 2011 20:25:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT