Re: QSA, the problem with ":scope", and naming

On 10/18/11 4:20 PM, Yehuda Katz wrote:
>   * Speeding up certain operations like `#foo` and `body`. There is *no
>     excuse* for it being possible to implement userland hacks that
>     improve on the performance of querySelectorAll.

Sure there is.  One such "excuse", for example, is that the userland 
hacks have different behavior from querySelectorAll in many cases.  Now 
the author happens to know that the difference doesn't matter in their 
case, but the _browser_ has no way to know that.

The other "excuse" is that adding special cases (which is what you're 
asking for) slows down all the non-special-case codepaths.  That may be 
fine for _your_ usage of querySelectorAll, where you use it with a 
particular limited set of selectors, but it's not obvious that this is 
always a win.

> This may be the result of browsers failing to cache the result of parsing selectors

Yep.  Browsers don't cache it.  There's generally no reason to.  I have 
yet to see any real-life testcase bottlenecked on this part of 
querySelectorAll performance.

>     or something else, but the fact remains that qSA can be noticably
>     slower than the old DOM methods, even when Sizzle needs to parse the
>     selector to look for fast-paths.

I'd love to see testcases showing this.

> jQuery also handles certain custom pseudoselectors, and it might be nice
> if it was possible to register JavaScript functions that qSA would use
> if it found an unknown pseudo

This is _very_ hard to reasonably unless the browser can trust those 
functions to not do anything weird.  Which of course it can't.  So your 
options are either much slower selector matching or not having this. 
Your pick.

-Boris

Received on Tuesday, 18 October 2011 20:41:06 UTC