Selector speed (was Re: Uploader Broken! > Re: [Commits] svn commit: 6068)
colin.clark at utoronto.ca
Wed Nov 19 23:13:27 UTC 2008
On 19-Nov-08, at 5:22 PM, Eli Cochran wrote:
> However, the slowness was because we rephrased our selector for
> fileRows from "tr:not(#queue-row-tmplt)" to ":not(#queue-row-tmplt)".
> tr:not(#queue-row-tmplt) means "all *row elements* that do not have an
> id of "queue-row-tmplt".
> :not(#queue-row-tmplt) means *any and all* elements that do not have
> an id of "queue-row-tmplt".
> so while the former forced jQuery to inspect every row element and
> return all but one of those rows, the latter selector forced jQuery to
> inspect each and every element in the container and return all but one
> of those.
> It's really quite surprising that all it did was slow down.
This is an interesting observation. Have you seen any good breakdowns
of the performance of particular selectors? Say, element type vs.
class selectors? It's clear that a more specific query will always be
faster. This is one of the reasons the DOM Binder encourages component
developers to scope our queries within a particular container.
As part of the optimization phase of component development, we should
probably assess the specificity of our default selectors and ensure
that they make a decent trade-off between flexibility and speed. The
nice thing about our "selectors" option is that, when people use their
own markup, they can also pass along custom selectors that run really
fast for their particular context. Our defaults can thus be optimized
for our default markup.
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work