W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 18 Oct 2011 16:40:37 -0400
Message-ID: <4E9DE445.2030901@mit.edu>
To: public-webapps@w3.org
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.

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC