【问题标题】：$('#id tag') vs. $('#id').find('tag') - which is preferable?$('#id tag') 与 $('#id').find('tag') - 哪个更可取？
【发布时间】：2012-07-15 04:44:39
【问题描述】：

我想知道哪个选项更好，尤其是在速度方面：

$('#id tag')...

或

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

另外，如果您将id 和/或tag 更改为class 或input:checked 之类的东西，同样的答案是否适用？

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

【问题讨论】：

尝试在jsperf.com中运行一个测试用例
是的，我已经跑了不少了。麻烦的是，我真的很想知道理论上的答案，而不仅仅是获得可能适用于我的特定测试条件的结果。
还有第三个选项：$("tag", "#id"); 当您进行性能测试时，请务必尝试所有三个选项。
@ravi jsperf 没问题，不同浏览器的结果不同
答案真的取决于你在说什么浏览器。例如，支持querySelectorAll 的浏览器和不支持的浏览器之间会有很大的不同。

标签： jquery performance

【解决方案1】：

您可以根据 3 件事做出决定：

可读性

这与您的两个给定选择器没有太大区别。就我而言，我更喜欢 $('#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 选择器在大多数浏览器中做得更好，因为它首先建立上下文，并且可以将降序选择器应用于更小的元素子集。

Here's a good performance test, if you want to know more about context-vs subset selectors performance in jQuery。 id 的子集一般规则。当然，您可以获得不同的结果，但在大多数情况下，它们确实如此。

所以，从我的角度来看，子集选择器是 3 到 0。

【讨论】：

【解决方案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() 是最快的，紧随其后的是第三种情况，第一种情况要慢得多。

【讨论】：

【解决方案3】：

在现代浏览器上，第一个 $("#id tag") 似乎比第二个 ($("#id").find("tag")) 慢很多； test here，请看下面的截图。 IE7（缺少querySelectorAll）以大致相同的速度运行它们。

但有两个观察结果：

实际上几乎不可能。如果您没有调试实际的已知性能问题，请不要担心。
综合基准总是值得怀疑的。如果您正在解决一个实际的、已知的性能问题，请分析 that（您的实际选择器和您的实际标记）。

【讨论】：

有趣。我原以为他们都在幕后遵循相同的功能。

【解决方案4】：

正如我所说 - 它在浏览器中有所不同。

铬：

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

即

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

【讨论】：

【解决方案5】：

后裔表现更好。检查此链接Jsperf 。

如果嵌套元素太多。然后去找。这确实是一个很小的差异。
这只是您方便的编码方式。如果嵌套项目太多，我更喜欢，然后我会去找，

【讨论】：

您的测试的问题在于您不只是在寻找 ID，而且可能大部分时间都花在了操作 CSS 上。细微的差别反映了这一点。检查我的性能结果，其中那些被消除并显示出截然不同的结果。 3次顺序的差异。

【解决方案6】：

此处的性能衡量标准：:)==> http://jsperf.com/find-vs-descendant-selector

似乎descendant 的方式更快，但在歌剧中表现不佳，

在我看来没关系:)

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

【讨论】：

谢谢。实际上是对保罗·爱尔兰的“演讲”的半回忆引发了这个问题。我似乎记得他说过 jQuery 引擎以不同的方式处理它们。我希望得到更全面的解释:)
下次见到 Paul 时向他打个招呼:P@Nick 很高兴很明显，我建议您自己进行性能测试，您知道如果您寻找它会变得更有趣内存泄漏 :P 是的，我说的是 ML 词 :) bruv！
我承认我不知道如何查找内存泄漏 :( 但我会跟 Paul 打个招呼...
@Nick 阅读了这个 bruv -blog.linkibol.com/2010/05/07/… *请注意这是旧博客，在“我们的”最喜欢的浏览器 I.E. :)
但是您的选择器不查找 ID 和标签，而是查找 ID 和带有 CSS 类的标签，这不一样。跨度>