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.
