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

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