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

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

From: Alex Russell <slightlyoff@google.com>
Date: Wed, 19 Oct 2011 01:08:33 +0100
Message-ID: <CANr5HFVJ29k5g_VU-Rrq=abqqbEQqMeE3MAEXOack48MsRFVcw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
On Tue, Oct 18, 2011 at 9:40 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

Most browsers try to optimize what is common. Or has that fallen out
of favor while I wasn't looking?

>> 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 Wednesday, 19 October 2011 00:09:30 UTC

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