jQuery selector performance

问题:

I'm having huge variations in performance depending on how I express my selectors. For example, look at these 2 selectors, which select exactly the same elements:

A) someTableRow.find("td.someColumnClass").find("span.editMode").find("input")
B) someTableRow.find("td.someColumnClass span.editMode input")

I would expect to B) to be faster as there is only 1 call, but in fact I'm finding A) executes around 8 times faster. I have no idea why, anyone have any insight? Thanks

回答1:

Presuming you are using at least jQuery 1.3 (i.e. with the addition of Sizzle), the performance you are seeing is due to the change in which the DOM is traversed. From here:

Up to and including jQuery 1.2.6 the selector engine worked in a "top down" (or "left to right") manner. jQuery 1.3.x (ie, Sizzle, which jQuery embeds) introduced a "bottom up" (or "right to left") approach to querying the DOM.

In your second example ("td.someColumnClass span.editMode input"), Sizzle effectively does this:

1. get all input elements inside someTableRow
2. for each input element found, traverse its ancestor tree for span elements with class="editMode". Remove input elements that don't have these ancestors
3. for each span.editMode element found, traverse its ancestor tree for td elements with class="someColumnClass". Remove input elements that don't have these ancestors

In your first example however, your are qualifying each step explicitly with each call to find(), defining a context and traversing down from there. You are enforcing the "top-down" approach. It is equivalent to passing in a context at each step, which is generally considered a performance booster:

$('input', $('span.editMode', $('td.someColumnClass', someTableRow)))

回答2:

Because you are reducing the context for the search.

In case B, it has to search through every DOM element to see if it meets the criteria.

In case A, is can quickly decide to ignore anything that's not "td.someColumnClass", then it can take that subset of the DOM and ignore anything that's not in "span.editMode". So it has a much smaller set of elements to search through to find "input"s now.

回答3:

A is more calls, but simpler. B is one call, but more complex. In this case, the complexity of the call greatly out-weighs the quantity of calls.

回答4:

The way JQuery handles selctors is a little different to CSS in my experience.

Reducing the context to the search is the key as Josh pointed out.

I find using the two parameter selectors really quick

How does this compare speed wise?

You don't need all the vars here it is just to make clear what I am doing.

var columnClasses = $('.someColumnClass');
var tableCell = $('td', columnclasses);
var editMode = $('.editmode', tableCell);
var spanInside = $('span', editMode);
var inputFinally = $('input', spanInside);

Kindness,

Dan

回答5:

I did some research on jQuery Selector Performance myself. A big problem are lookups by classname on Internet Explorer. IE doesnt support getElementsByClassName - therefore jQuery and other frameworks "reimplement" it in JavaScript by iterating through all DOM elements. Check out the following analysis blog about jQuery Selector Performance

回答6:

There's a really interesting article on selector performance here: http://blogs.atlassian.com/developer/2009/08/jquery_bondage.html

In it, the author shows a "bind" jQuery extension that shows how many times the function is evaluated.