- From: Keean Schupke <keean@fry-it.com>
- Date: Wed, 4 May 2011 21:24:59 +0100
- 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>
- Message-ID: <BANLkTimLF6eo2=y+wRPFSH9PtBm5h89n5g@mail.gmail.com>
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 UTC