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 _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
