What is fastest children() or find() in jQuery?

前端 未结 6 1951
悲&欢浪女
悲&欢浪女 2020-11-22 13:43

To select a child node in jQuery one can use children() but also find().

For example:

$(this).children(\'.foo\');

gives the same result

相关标签:
6条回答
  • 2020-11-22 14:34

    Both find() and children() methods are used to filter the child of the matched elements, except the former is travels any level down, the latter is travels a single level down.

    To simplify:

    1. find() – search through the matched elements’ child, grandchild, great-grandchild... all levels down.
    2. children() – search through the matched elements’ child only (single level down).
    0 讨论(0)
  • 2020-11-22 14:37

    This jsPerf test suggests that find() is faster. I created a more thorough test, and it still looks as though find() outperforms children().

    Update: As per tvanfosson's comment, I created another test case with 16 levels of nesting. find() is only slower when finding all possible divs, but find() still outperforms children() when selecting the first level of divs.

    children() begins to outperform find() when there are over 100 levels of nesting and around 4000+ divs for find() to traverse. It's a rudimentary test case, but I still think that find() is faster than children() in most cases.

    I stepped through the jQuery code in Chrome Developer Tools and noticed that children() internally makes calls to sibling(), filter(), and goes through a few more regexes than find() does.

    find() and children() fulfill different needs, but in the cases where find() and children() would output the same result, I would recommend using find().

    0 讨论(0)
  • 2020-11-22 14:40

    children() only looks at the immediate children of the node, while find() traverses the entire DOM below the node, so children() should be faster given equivalent implementations. However, find() uses native browser methods, while children() uses JavaScript interpreted in the browser. In my experiments there isn't much performance difference in typical cases.

    Which to use depends on whether you only want to consider the immediate descendants or all nodes below this one in the DOM, i.e., choose the appropriate method based on the results you desire, not the speed of the method. If performance is truly an issue, then experiment to find the best solution and use that (or see some of the benchmarks in the other answers here).

    0 讨论(0)
  • 2020-11-22 14:42

    Here is a link that has a performance test you can run. find() is actually about 2 times faster than children().

    Chrome on OSX10.7.6

    0 讨论(0)
  • 2020-11-22 14:42

    None of the other answers dealt with the case of using .children() or .find(">") to only search for immediate children of a parent element. So, I created a jsPerf test to find out, using three different ways to distinguish children.

    As it happens, even when using the extra ">" selector, .find() is still a lot faster than .children(); on my system, 10x so.

    So, from my perspective, there does not appear to be much reason to use the filtering mechanism of .children() at all.

    0 讨论(0)
  • 2020-11-22 14:43

    Those won't necessarily give the same result: find() will get you any descendant node, whereas children() will only get you immediate children that match.

    At one point, find() was a lot slower since it had to search for every descendant node that could be a match, and not just immediate children. However, this is no longer true; find() is much quicker due to using native browser methods.

    0 讨论(0)
提交回复
热议问题