Selector speed (was Re: Uploader Broken! > Re: [Commits] svn commit: 6068)

[Colin Clark]

Eli,

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".
>
> while
>
> :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.

Interesting stuff,

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org