$('#id tag') 和 $('#id').find('tag') 哪一个更好？（涉及 IT 技术）

Question

我想知道哪个选项更好，特别是从速度方面考虑：

$('#id tag')...

或者

$('#id').find('tag')...

另外，如果你将id和/或tag更改为类似于class或input:checked之类的内容，是否适用相同的答案呢？

例如，哪个更好：$('#id input:checked')...还是$('#id').find('input:checked');？

- Nick

---

请在 http://jsperf.com 上尝试运行测试用例。 - Ravi Gadag

还有第三个选项：$("tag", "#id"); 在进行性能测试时，请确保您尝试所有三种选项。 - Robert Koritnik

@ravi jsperf还可以，但是不同的浏览器之间会有不同的结果。 - Royi Namir

答案取决于你所谈论的浏览器。例如，支持 querySelectorAll 的浏览器和不支持的浏览器之间会有很大的差异。 - James Allardice

感谢您的帮助和鼓励，@DavidThomas。 - Nick

Answer 1

你可以基于三个方面做出决策：

阅读性 这两种选择器之间没有太大区别。我自己更喜欢使用$('#id').find('inner')语法，因为它更准确地描述了它实际正在执行的操作。

可重用性 如果你的代码中有其他部分使用相同的 id 选择器（或其上下文中的某些内容），你可以缓存该选择器并重复使用它。我自己发现，对于被编写成$('#id inner')这样的形式的代码进行重构更加困难，因为你必须先解码 CSS 选择器，然后才能继续寻找可能的改进。

想象一下这两种情况都不是很复杂。

$('#hello .class_name tag').doThis();
$('#hello .other_name input').doThat();

还有另一种情况

$('#hello').find('.class_name tag').doThis();
$('#hello').find('.other_name input').doThat();

我认为第二个例子明显地提醒你“缓存id选择器”，而第一个例子没有。

速度

性能总是一个很好的点，在这种情况下，带有find的id选择器在大多数浏览器中表现更好，因为它首先建立上下文，然后可以将下降选择器应用于更小的元素集合。

这里有一个好的性能测试，如果您想了解jQuery中上下文和子集选择器性能的更多信息。子集id 通常 是最佳选择。当然，你可能会得到不同的结果，但在大多数情况下，他们是如此。

因此，从我的角度来看，子集选择器比上下文选择器快3倍。

- Beat Richartz

Answer 2

以下是需要翻译的内容：

这里是测试用例HTML，我要查找所有在#i元素下的span元素：

<div id="i">
  <span>testL1_1</span>
  <span>testL1_2</span>
  <div>
    <span>testL2_1</span>
  </div>
  <ul>
    <li>
      <span>testL3_1</span>
    </li>
  </ul>
  <div>
    <div>
      <div>
        <div>
          <span>testL5_1</span>
        </div>
      </div>
    </div>
  </div>
</div>

测试这三个jQuery选择器：

$("#i span");         // much slower
$("#i").find("span"); // FASTEST
$("span", "#i");      // second fastest

http://jsperf.com/jquery-sub-element-selection

在Google Chrome和Firefox中测试，结果表明.find()是最快的，其次是第三种情况，而第一种情况则慢得多。

- Robert Koritnik

Answer 3

这里的性能指标为：:)==> http://jsperf.com/find-vs-descendant-selector

看起来descendant的方式略快，但在Opera上表现不佳，

总之，在我看来，这并不重要:)

希望这回答了您的问题，并请查看此处Is .find() faster than basic descendant selecting method?

- Tats_innit

---

谢谢。实际上，这是Paul Irish的“讲座”的半记忆引发了这个问题；我似乎记得他说jQuery引擎以不同的方式处理它们。我希望能得到更详细的解释 :) - Nick

下次见到保罗时，请向他问好 :P @Nick 很高兴这很清楚，我建议你应该自己进行性能测试，如果你寻找内存泄漏，它会变得更有趣 :P 是的，我说了ML这个词 :) 兄弟！ - Tats_innit

但是你的选择器并不是寻找ID和标签，而是带有CSS类的ID和标签，这并不相同。 - Robert Koritnik

@RobertKoritnik 嗯，我认为 O 很值得 DV，:) 请随意 DV，但还是谢谢你，兄弟！ - Tats_innit

哦，它并不是那么无效以至于应该被踩。我给@Utkanos的推测性回答打了-1分，后来他们删除了回答，因为它是基于猜测而非真实数据。 - Robert Koritnik

Answer 4

似乎第一个选择器$("#id tag")在现代浏览器上比第二个选择器（$("#id").find("tag")）要慢得多；请参考此处的测试，以下是屏幕截图。IE7（缺少querySelectorAll）以大致相同的速度运行它们。

但有两点需要注意：

1. 实际上这几乎不可能有任何影响。如果您没有调试实际已知的性能问题，请不要担心。

2. 合成基准测试结果总是值得怀疑的。如果您正在处理实际已知的性能问题，请分析那个（您实际的选择器和您实际的标记）。

- T.J. Crowder

---

有趣。我本以为它们在幕后都遵循同样的功能。 - Mitya

Answer 5

Descendant performs better. check for this link Jsperf .

1. 如果您有太多嵌套元素，请使用find。这只是一个很小的差异。
2. 这只是您编码的方便方式。如果有太多嵌套项，我更喜欢使用find。

- Ravi Gadag

---

你的测试问题在于你不仅仅是查找ID，而且大部分时间可能花费在操作CSS上。这些微小的差异反映出来了。请查看我的性能结果，其中这些因素被消除，并显示出非常不同的结果。差异达到3倍之多。 - Robert Koritnik

Answer 6

就像我说的一样 - 在不同的浏览器中会有所不同。

Chrome：

http://i.stack.imgur.com/SijQY.jpg

ie

http://i.stack.imgur.com/axhGw.jpg

- Royi Namir