1

所以在我的应用程序中，用户可以在某些 div 标签内创建一些内容，并且每个内容，或者我称之为“元素”的内容都有自己的对象。目前，我使用一个函数来计算元素已使用 jquery 选择器放置在其中的原始 div 标记，但我想知道在性能方面，一旦元素具有存储对 div 标记的引用会不会更好已创建，而不是稍后计算？所以现在我使用这样的东西：

$('.div[value='+divID+']')

但相反，当我创建元素时，我可以将引用存储在元素内。这对性能会更好吗？

4

4 回答 4

4

如果您有很多这样的绑定，最好存储对它们的引用。正如评论中提到的，变量查找比在 DOM 中查找要快得多——尤其是使用您当前的方法。jQuery 选择器比纯 DOM 选择器要慢，而且那个特定的选择器会非常慢。

这是一项基于 epascarello 的测试，显示了 jQuery、DOM2 方法和引用之间的区别：http: //jsperf.com/test-reference-vs-lookup/2。变量赋值超快如预期。此外，DOM 方法以同样大的优势击败了 jQuery。注意，这是以雅虎主页为例。

另一个考虑因素是 DOM 的大小和复杂性。随着这增加，参考缓存方法变得更加有利。

于 2012-08-02T20:59:19.617 回答
2

与每次查找相比，局部变量将非常快。测试证明它。

于 2012-08-02T21:00:36.327 回答
1

jQuery 是一个构建和返回对象的函数。这部分不是特别昂贵，但实际的 DOM 查找确实涉及相当多的工作。对于匹配现有 DOM 方法（如 getElementById 或 getElementsByClassName （在 IE8 中不存在，所以它真的很慢）的简单查询的开销并不高）但是是的，区别在于工作（构建一个包装 DOM 访问的对象方法）并且几乎没有工作（引用现有对象）。如果您打算重用它们，请始终缓存您的选择器结果。

此外，您使用的 xpath 东西在某些浏览器中可能非常昂贵，所以是的，我肯定会缓存它。

需要注意的事项：

  • 没有 ID 的长系列 JQ 参数
  • 在 IE8 或更少的类中只有一个类的选择器（添加标签名称，例如 'div.someClass'）以获得显着改进 - IE8 及更低版本必须在解释器级别访问每一段 HTML，而不是在您只使用快速的本机方法时使用类
  • xpath 风格的查询（很多较新的浏览器可能会处理这些问题）

在编写选择器时，请考虑必须查看多少标记才能找到它。如果您知道您只想要某个 ID 内的某个类的 div，请执行其中一项 $('#theID div.someClass') 而不仅仅是 $('div.someClass');

但是不管怎样，只是根据工作避免的原则，如果你要使用它两次或更多次，缓存该值。并尽可能避免使用重复请求来骚扰 DOM。

于 2012-08-02T21:05:53.760 回答
0

通过 ID 查找元素非常快。我不是 100% 确定我理解你的其他方法，但我怀疑它会比通过它的 id 简单查找元素更好，浏览器知道如何最好地完成这项任务。根据您的解释，我看不出您的方法会更快。

于 2012-08-02T20:50:00.730 回答