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
