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