Question

我正在阅读Brandon Aaron撰写的这篇文章here，关于jquery上下文如何帮助。所以我想做一个自己的测试。所以这就是我所做的。

在前面创建的“#context”中创建了一个id =“context”的DIV和嵌套的DIV，其中id =“holder”。
创建深度为18的嵌套DIV并将<div id="context"><div id="holder"></div></div>附加到其上，从而生成20个嵌套DIV
现在我通过以下选择器测试了访问“#holder”的时间：
一个。 $("#holder") // no context
湾$("#holder", "#context") // with "#context" selector string
C。 $("#holder", $("#context")) // sending jquery object each time with selector "#context"
d。 $("#holder", $context) // where, var $context = $("#context"). Caching jquery obj
记录了访问X = 1000次以及开始和结束时间差的每种情况。我发现时间用于：
案例（a）是最不一致的28-32毫秒[jquery-1.3.2]
情况（b）+（c）的最高时间为60-65毫秒＆amp;分别为70-75毫秒情况（d）有40-50毫秒，有1或2个加标值。

此类基本检查有效吗？您可以在JSBIN中使用JS代码here。 [请让我知道如果我可以改进这个测试一些如何]
如果是，那么这个“背景”真的有用吗？

#NOTE：在jsbin编辑模式下用jquery-1.4.2替换jquery-1.3.2，你会惊讶地看到数字突然增加：P

Answer 1

如果您正在搜索更大的DOM，则上下文确实很有用。搜索ID已经非常快，在这种情况下，上下文并没有真正帮助那么多。当您通过标签名称或类别进行选择时，上下文可以真正发挥作用。

当您在DOM中增加项目数量时，您可以真正看到时间变得更好，http://jsbin.com/aciji4/6

Answer 2

使用上下文（而不是单独使用选择器）需要更长的时间是有意义的，因为在内部，上下文使用.find（）方法，所以实质上，你所做的只是

$('#context').find('#holder');

我主要认为它是一种更简单的方法来识别上下文发生变化的事件和迭代器中的元素，因为

$('.holder', this)

比

更漂亮

$(this).find('.holder')

Answer 3

#ID选择器依赖于浏览器本机document.getElementById。无论如何，它都会很快。

尝试使用div.class [attribute = value]这样的选择器，有或没有上下文。例如*，您可以使用此选择器选择右侧的“相关”问题链接：

// Selects anchor elements with href's beginning with /questions/
$('a[href^=/questions/]')

但是，更快地限制选择器引擎必须迭代的锚元素数量，评估相对昂贵的文本匹配：

$('a[href^=/questions/]', '.related')

*为了便于讨论，忽略了这些链接上明显更容易的.question-hyperlink类。

Answer 4

对于它的价值，$context = $("#context")仍在使用jQuery对象，然后必须将其转换为DOM对象。

如果您使用$context = $("#context")[0]，您会发现它的运行速度与第一次测试一样快。

Answer 5

我已经使用了JSBin代码并将其放入jsPerf Test

$ context.find（'。holder'）是其最接近的竞争对手的两倍，$（'。holder'，$ context），这是一个好的快十倍比使用的任何其他选择器都要好。

总之，缓存选择器并使用.find（）获得最佳性能

Answer 6

在重构代码之前要小心。正如#NOTE编写的那样，jQuery自1.4以来的工作方式完全不同。最新版本可能包含更多优化。

我修改了上面的jsbin代码以获得最近的jQuery，并添加了一些其他案例。你会看到，现在只有那三（2,3,6）个案例得到了性能损失，每轮创建一个jQuery对象。休息在同一时间运行。

您可以在此处找到修改后的版本：http://jsbin.com/aciji4/63/