jQuery에서 가장 빠른 children () 또는 find ()는 무엇입니까?


320

jQuery에서 자식 노드를 선택하기 위해 children ()과 find ()를 사용할 수 있습니다.

예를 들면 다음과 같습니다.

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

다음과 같은 결과를 제공합니다.

$(this).find('.foo');

이제 어떤 옵션이 가장 빠르거나 선호되며 왜 그렇습니까?


27
.find().children()동일하지 않습니다. 후자는 하위 선택기와 같이 DOM 트리 아래로 단일 레벨 만 이동합니다.
Timothy003

1
@ Timothy003 당신은 그것을 잘못 설명했습니다, 전자는 후자가 아닌 단일 레벨을 여행합니다
Dipesh Rana

5
@DipeshRana '후보'는 질문이 아닌 Timothy003의 자체 문장에 적용되었습니다.
Jayesh Bhoot 2016 년

1
이 문제를 제기 해 주셔서 감사합니다. 많은 경우 성능 차이는 사소하지만 문서에서는 실제로이 두 가지 방법이 다르게 구현되었다고 언급하지 않습니다! 모범 사례를 위해 find()거의 항상 빠르다는 것을 아는 것이 좋습니다 .
Steve Benner

그렇기 때문에 나는 영어로 된 "후자"나 "후자"를 좋아하지 않았습니다. 무슨 뜻인지 말해봐 esh.
크리스 워커

답변:


415

children()반면 아니라, 노드의 직계 자식에 보이는 find()이송이 노드 아래의 전체 DOM은, 그래서 children() 해야 빨리 해당 구현을 제공한다. 그러나 find()사용하는 네이티브 하면서, 브라우저 방법을 children()사용하는 자바 스크립트가 브라우저에서 해석했다. 필자의 실험에서는 일반적인 경우 성능 차이가별로 없습니다.

어느 것을 사용할 것인지는 DOM에서 직계 자손 또는이 노드 아래의 모든 노드 만 고려할지 여부에 따라 달라집니다. 즉, 메소드 속도가 아니라 원하는 결과를 기반으로 적절한 메소드를 선택하십시오. 성능이 실제로 문제라면 최상의 솔루션을 찾아서 사용해보십시오 (또는 다른 답변의 일부 벤치 마크 참조).


9
물론 부모 요소에 자식 노드 만있는 경우 어떻게됩니까? 이것에 대한 프로파일 링을 할 것입니다.
Jason

11
어린이 대 찾기의 성능은 브라우저와 DOM 하위 트리의 검색이 얼마나 복잡한 지에 따라 다릅니다. 현대 브라우저에서 find ()는 내부적으로 querySelectorAll을 사용하여 복잡한 선택기 및 중소 규모 DOM 하위 트리에서 children ()보다 쉽게 ​​성능을 향상시킬 수 있습니다.
르자 레드

실험의 정량적 결과를 제공하는 데 도움이됩니다.
누가 복음

5에서 20 사이의 계층 구조 중첩이있는 모든 테스트에서 find ()는 항상 children ()보다 성능이 뛰어납니다. (Chrome 54에서 테스트 됨) 나는 그 반대를 예상했습니다. 이제부터는 쉬운 방법을 사용하여 children (). children (). children ()을 통해 요소를 순회하는 대신 내 요소를 찾을 수 있습니다 (...).
Ruwen

179

jsPerf 테스트 는 find ()가 더 빠르다는 것을 나타냅니다. 좀 더 철저한 테스트를 만들었고 여전히 find ()가 children ()보다 우수한 것처럼 보입니다.

업데이트 : tvanfosson의 의견에 따라 16 단계의 중첩으로 다른 테스트 사례 를 만들었습니다 . find ()는 가능한 모든 div를 찾을 때만 느리지 만 find ()는 div의 첫 번째 레벨을 선택할 때 여전히 children ()보다 성능이 뛰어납니다.

children ()은 100 레벨 이상의 중첩이 있고 find ()가 통과하기 위해 약 4000+ div가있을 때 find ()보다 성능이 우수합니다. 기본 테스트 사례이지만 여전히 대부분의 경우 find ()가 children ()보다 빠르다고 생각합니다.

Chrome 개발자 도구에서 jQuery 코드를 단계별로 살펴 보았으며 children ()이 내부적으로 sibling (), filter ()를 호출하고 find ()보다 몇 가지 더 많은 정규 표현식을 거치는 것을 알았습니다.

find ()와 children ()은 다른 요구를 충족하지만 find ()와 children ()이 동일한 결과를 출력하는 경우 find ()를 사용하는 것이 좋습니다.


4
아이들은 dom traversal 방법을 사용하고 find는 selector api를 사용하는 것으로 보입니다.
topek

4
하나의 중첩 수준 만 있기 때문에 테스트 사례가 상당히 줄어 듭니다. 일반적인 경우를 원한다면 임의의 중첩 깊이를 설정하고 find ()가 children ()보다 더 깊은 트리를 통과 할 때 성능을 확인해야합니다.
tvanfosson

특정 단일 하위 요소 (예 : event.target)가 특정 dom 요소 (예 : $ ( '. navbar'))에 있는지 확인하는 경우 $ .contains (this, event.target)가 훨씬 빠릅니다. (가장 빠른 jquery 검색의 경우 8,433,609 / 초 대 140k). jsperf.com/child-is-in-parent
Chris Sattinger

92

다음은 실행할 수있는 성능 테스트 가 있는 링크 입니다. find()실제로보다 약 2 배 빠릅니다 children().

OSX10.7.6의 Chrome


$ .contains (document.getElementById ( 'list'), $ ( '. test') [0])는 초당 8,433,609입니다. 특정 요소가 있고 B가 A에 있는지 알고 싶다면 이것이 가장 좋습니다. jsperf.com/child-is-in-parent
Chris Sattinger

좋은 시험입니다. var $test = $list.find('.test');$ list가 jQuery 객체 인 곳 과 같은 작업을 수행하면 더 빨라질 수 있습니다 . jsperf.com/jquery-selectors-context/101
Maciej Krawczyk

24

사람들은 반드시 동일한 결과를 제공하지 않습니다 : find()당신에게 얻을 것이다 후손 노드를, 반면 children()단지 당신을 얻을 것이다 직접적인 아이를 일치하는지 확인합니다.

한 시점에서 find()직계 자식뿐만 아니라 일치 할 수있는 모든 자손 노드를 검색해야했기 때문에 훨씬 느려졌습니다. 그러나 이것은 더 이상 사실이 아닙니다. find()기본 브라우저 방법을 사용하기 때문에 훨씬 빠릅니다.


1
다른 답변 haha ​​: p에 따르면 아닙니다. 매우, 매우, 매우 큰 DOM 트리가
있을 때만

1
@Camou이 답변은 4 살입니다. find()당시 훨씬 느렸다!
John Feminella

@camou는 성능 부분이 "다른 답변에 따르지 않았다"고 말합니다. 이 답변의 첫 번째 단락이 정확합니다.
Don Cheadle

14

다른 답변 중 어느 것도 사용하는 경우 처리되지 .children()또는 .find(">")유일한 부모 요소의 직접적인 아이를 검색합니다. 그래서 나는 어린이를 구별하는 세 가지 다른 방법을 사용하여 jsPerf 테스트를 만들어을 알아 냈습니다 .

추가 ">"선택기를 사용하는 경우에도 .find()여전히 발생하는 것보다 훨씬 빠릅니다 .children(). 내 시스템에서는 10 배입니다.

내 관점에서 볼 때 필터링 메커니즘을 사용해야 할 이유가 많지 않습니다 .children().


3
이 의견에 감사드립니다! jQuery가 .children (x)을 .find ( ">"+ x)의 별칭으로 바꾸어야하는지 궁금하지만, 다른 생각은 없을 것입니다.
마이클 스캇 커스버트

1
이것은 가장 적절한 비교 인 것 같습니다. 감사!
GollyJer

3

모두 find()children()임의의 레벨 아래로 이동하는 전자는 제외 방법 후자는 하나의 레벨 아래로 이동하고, 상기 정합 소자의 아이를 필터링하는 데 사용된다.

단순화하려면 :

  1. find() – 일치하는 요소의 자식, 손자, 증손자를 검색하십시오.
  2. children() – 일치하는 요소의 자식 만 검색합니다 (단일 레벨 다운).
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.