Re: [selectors-api] Summary of Feature Requests for v2

Boris Zbarsky wrote:
> On 9/24/09 6:29 AM, Sean Hogan wrote:
>> I would be surprised if an implementation didn't create an internal
>> lookup table keyed off the selector text.
>
> Gecko doesn't.  Webkit doesn't.
>
> I just checked really quickly, and on my machine (a year-plus old 
> laptop) parsing the ".foo .bar .baz" selector and destroying the 
> selector object before returning in Gecko takes about 80% of the 
> "overhead" (that is, not walking the tree and doing selector matching) 
> time of a querySelector() call.  Or, in numbers, about 5.5us per call. 
> Webkit's time for executing my testcase is comparable, though I can't 
> tell how much of their time is selector parsing.
>

That is surprising. Does the CSS engine do the same? If the CSS engine 
doesn't store the parsed selector then it probably doesn't matter for JS 
calls either.

> If you're doing less than 1,000 calls that involve selectors api per 
> second, the selector-parsing time is probably not that relevant.  But 
> I don't know what the use cases are here.
>
> -Boris
>
Take a event-delegation system that uses matchesSelector.
Every event that it handles will walk the event path trying 
element.matchesSelector with every registered handler.
e.g. There are twenty registered click handlers and a click event occurs 
on an element ten levels deep. There could be 20 * 10 = 200 calls to 
matchesSelector. Or 400 if the system simulates capture phase as well.

Or take a framework that adds enhancements to HTML elements based on 
selectors.
The framework wants to handle dynamic insertion to / removal from the 
page, so every DOMNodeInserted / DOMNodeRemoved (or equivalent) it will 
call querySelectorAll for all registered enhancements to see if there is 
any work to do.

Received on Thursday, 24 September 2009 22:45:48 UTC