- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 24 Sep 2009 15:06:21 -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:41 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> > 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.
Btw, i got word from our JS engine guys that using
Array.map/Array.filter has bad performance behavior in firefox right
now (it makes you fall off trace). So if you run any perf tests it'd
probably be better not to use those functions, which is probably a
good idea anyway given that I don't think they work in all browsers
yet.
/ Jonas
Received on Thursday, 24 September 2009 22:07:20 UTC