I have found that row.find("td.someClass span.otherClass") is
significantly slower than row.find("td.someClass > span.otherClass").
Performance of the ancestor/descendant selector is linearly dependent
on the amount of other elements on the page, outside the row element,
whereas the parent/child selector is unaffected. This suggests that
the ancestor/descendant query is parsing elements outside of the row,
even though the query should be scoped to the row. Is this expected,
or is this something that can be improved in the jQuery selector
engine?
Specifically, I have the following conditions:
* row is a jQuery wrapped set containing one <tr> element
* There are many rows in the table containing the row
* There is a small number of cells in the row, of which one has class
someClass (so the scope of the query is small)
* Every td in the row contains "<span class='otherClass'> some text </
span>" and no other content. One child, no grandchildren. There is not
a large tree of descendant elements to search, so there's no obvious
reason why searching descendants should be slower than searching
children.
* The number of rows in the table affects performance of the ancestor/
descendant selector linearly, but does not affect the parent/child
selector. This suggests that the ancestor/descendant query is parsing
the whole table.
With 5 cells in each row, one of which has someClass, I get the
following results.
With 100 rows, the Firebug profiler reports an average of 110ms for
row.find("td.someClass span.otherClass") and 0.673ms for row.find
("td.someClass > span.otherClass").
With 1000 rows, the Firebug profiler reports an average of 1080ms for
row.find("td.someClass span.otherClass") and 0.726ms for row.find
("td.someClass > span.otherClass").
With 4000 rows, the Firebug profiler reports an average of 4623ms for
row.find("td.someClass span.otherClass") and 0.753ms for row.find
("td.someClass > span.otherClass").
This gist contains a page demonstrating the problem.
http://gist.github.com/170290
