views:

937

answers:

2

As far is I know, there are a number of ways of selecting child elements in jQuery.

//Store parent in a variable  
var $parent = $("#parent");

Method 1 (by using a scope)

$(".child", $parent).show();

Method 2 (the find() method)

$parent.find(".child").show();

Method 3 (For immediate children only)

$parent.children(".child").show();

Method 4 (via CSS selector) - suggested by @spinon

$("#parent > .child").show();

Method 5 (identical to Method 2) - according to @Kai

$("#parent .child").show();

I'm not familiar with profiling to be able to investigate this on my own, so I would love to see what you have to say.

Thanks in advance,

Marko

P.S. I understand this is a possible duplicate of this question but it doesn't cover all methods.

+34  A: 

Method 1 and method 2 are identical with the only difference is that method 1 needs to parse the scope passed and translate it to a call to $parent.find(".child").show();.

Method 4 and Method 5 both need to parse the selector and then just call: $('#parent').children().filter('.child') and $('#parent').filter('.child') respectively.

So method 3 will always be the fastest because it needs to do the least amount of work and uses the most direct method to get first-level children.

Based on Anurag's revised speed tests here: http://jsfiddle.net/QLV9y/1/

Speed test: (More is Better)

On Chrome, Method 3 is the best then method 1/2 and then 4/5

alt text

On Firefox, Method 3 is still best then method 1/2 and then 4/5

alt text

On Opera, Method 3 is still best then method 4/5 and then 1/2

alt text

On IE 8, while slower overall than other browsers, it still follows the Method 3, 1,2,4,5 ordering.

alt text

Overall, method 3 is the overal best method to use as it is called directly and it doesn't need to traverse more than one level of child elements unlike method 1/2 and it doesn't need to be parsed like method 4/5

Though, keep in mind that in some of these we are comparing apples to oranges as Method 5 looks at all children instead of first-level ones.

Aaron Harun
By identical you mean that they both use the same logic to search?
Marko
Don't you mean that method 1 and 2 are identical?
Guffa
Yes, yes I do. :)
Aaron Harun
Thanks @Aaron - tI'd like to see what the others think, I will accept your answer if everyone agrees. Cheers :)
Marko
"parse the scope passed" ?
J-P
@J-P, I mean it needs to take the extra bit of time to recognize that a scope is being passed to translate it into the `$parent.find(".child");` command.
Aaron Harun
spot on @Aaron - http://jsfiddle.net/QLV9y/
Anurag
Well those results contradict Method 4, since it takes the longest to complete. Does .filter(".child") really take that long to complete? If Method 4 calls children() then filter() we shouldn't see that much of a delay?
Marko
Also @Aaron - Are you able to add @Anurags link to your answer? It's an excellent test :) Furthermore, Method 1 and 2 don't appear to be identical, the scoped test seems to be running slightly faster, as opposed to the other way around.
Marko
@marko, for me, scoped runs about 300 operations/second slower. For method 4, the loss is in parsing the string into the functions not calling the functions. @anurag, thanks that works perfectly.
Aaron Harun
That's an interesting result then, what browser are you using? On average, scoped runs about 200 op/s faster for me. In Firefox 3.6.4
Marko
I'm using firefox 3.6 see http://tinyurl.com/2e89tp5 for my stats, on chrome I got very different numbers (see image in post above). But if you run it multiple times in a row, you'll find that the numbers change. Opera was really surprising, Method 1/2 are the slowest on it: http://tinyurl.com/2a9r9r8
Aaron Harun
@Aaron @Marko - The tests might be a little skewed as we're always using the root node as context, and the document is pretty big. Despite that, I'm seeing 1 and 2 line up within 20 ops/sec to each other on most runs. Compared to 1 and 2, 4 is about 100-200 ops slower, and 5 is about 400 ops slower which is understandable because it goes through all descendants and not just children. Chart - http://tinyurl.com/25p4dhq
Anurag
That's excellent, thanks to everyone for their input. @Aaron, if you could just add a note that Method 3 only finds immediate descendants, we don't want people to confuse it with the other 4. Also, here's an IE8 reference, had to download a .php file to extract the URL :) http://tinyurl.com/2a8ag59
Marko
@Aaron Harun: Just a hint: if you want to create JSLitmus-based JavaScript performance test cases more easily, just use [jsPerf](http://jsperf.com/).
Mathias Bynens
+3  A: 

Method 1

Can't be shorter and faster using jQuery. This call directly gets down to $(context).find(selector) (method 2, due to optimazation) which in turn, calls getElementById.

Method 2

Is doing the same, but without some uneccesary internal function calls.

Method 3

using children() is faster than using find(), but of course, children() will only find direct childrens of the root element whereas find() will search recursivly top-down to all child elemens(including sub child elements)

Method 4

Using selectors like this, has to be slower. Since sizzle (which is the selector engine from jQuery) works right to left, it will match ALL classes .child first before it looks if they are a direct child from id 'parent'.

Method 5

As you stated correctly, this call will also create a $(context).find(selector) call, due to some optimazation within the jQuery function, otherwise it could also go through the (slower) sizzle engine.

jAndy
You're not talking about the var $parent = $("#parent") are you? I can't see how Method 1 could use getElementById when the element has a class?
Marko
@jAndy, I wanted to agree but, in method 1, docs says, `Internally, selector context is implemented with the .find() method` -please update, I know you got confused on the labels of the OP :)
Reigel
@Reigel: true fixed that. @Marko: parsing `#parent` represents an id, if it is a class, it will not use `getElementById` obviously.
jAndy