- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 24 Sep 2009 14:41:02 -0700
- To: John Resig <jresig@mozilla.com>
- Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>
On Thu, Sep 24, 2009 at 2:09 PM, John Resig <jresig@mozilla.com> wrote:
>
>> My concern with this API is that it forces the implementation to
>> always sort the array, even if already sorted, and then do a merge
>> sort on the individual results from querySelectorAll. It would be
>> faster to simply run the query on each node, and then merge sort the
>> results.
>
> That's not a huge issue - if a NodeList is coming in then we can assume that
> it's already containing unique results and is in document order. It's only
> if it's an array that we have to do the dance. Even in the case where the
> array of results is already in document order the sort will be incredibly
> fast (O(N)).
Note that we'd have to do the same work that a JS implementation that
uses Node.compareDocumentPosition. The only win if we have to sort is
that we wouldn't be crossing the JS<->C++ bridge as much. The actual
computations would be exactly the same.
>> > If this is how it's implemented it actually becomes really useful to
>> > have
>> > the NodeList-based element filtering.
>> >
>> > document.createNodeList([ ... some elements ...
>> > ]).filterSelector("em,
>> > strong")
>> >
>> > (Since this would be much faster than using Array.filter or some other
>> > method.)
>>
>> Are you sure that Array.filter would result in a significant perf hit?
>> What with recent jitting and stuff it would be great if we don't have
>> to rely on making everything a native method, but can rely on
>> javascript to do part of the work without taking too much of a perf
>> hit.
>
> I can guarantee that it'll be slower than doing it natively - especially so
> in Internet Explorer 8.next (the more that they do under the covers the
> faster we can provide results).
One could argue that microsoft should just shape up and supply a
modern JS engine ;)
In all seriousness though. It'd be nice to get data here. I'm wary of
adding APIs that are there just to work around slowness in
implementations, unless the wins are significant. Once we've added an
API we have to maintain it until the end of time, long after
performance improvements have made them obsolete.
There's definitely cases when this makes sense to do, however it'd be
nice with data to back up that this is one of those times.
/ Jonas
Received on Thursday, 24 September 2009 21:42:04 UTC