最小化 jQuery 实例与创建更多实例
我开始发表一系列关于 javascript / jQuery 优化的帖子，并偶然发现了这个有趣的结果。
为什么最小化 jQuery 对象（通过从缓存的 jQuery 集合中搜索）会比创建更多 jQuery 对象实例慢？
我惊讶地看到我准备的测试结果。 我一直认为最小化创建 $ 实例会更慢。
这是我习惯写的，因为我缓存了父级（我称之为“appRoot”）。
var appRoot = $("#appRoot");
appRoot.find(".element1").css("color","red");
appRoot.find(".element2").css("color","blue");
vs
$(".element1").css("color","red");
$(".element2").css("color","blue");
查看测试结果（场景略有不同）。 jsperf minimize-jquery-object-creation 事实证明，缓存的代码片段速度较慢然后是未缓存的片段。
我试图理解为什么？
I started a series of posts on javascript / jQuery optimization and stumbled upon this interesting result.
Why is it that minimizing jQuery objects (by searching from a cached jQuery collection) can be slower then creating more instances of jQuery objects?
I was stunned to see the results of a test i prepared.
I always thought that minimizing creating $ instances are slower.
This is what i am used to write, as i cache the parent (i call it "appRoot").
var appRoot = $("#appRoot");
appRoot.find(".element1").css("color","red");
appRoot.find(".element2").css("color","blue");
vs
$(".element1").css("color","red");
$(".element2").css("color","blue");
See the test results (slightly different scenario).
jsperf minimize-jquery-object-creation it turns out that the cached snippet is slower then the uncached snippet.
I am trying to understand why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为 find() 调用是减慢速度的原因。
缓存 jQuery 对象的唯一原因是您要多次引用或操作它。如果您只是设置 CSS 属性，并且该属性在渲染页面的生命周期内不会更改，那么就没有理由定义缓存变量。
I think the find() call is what's slowing things down.
The only reason to cache a jQuery object is if you're going to be referencing or manipulating it multiple times. If you're just setting a CSS property and that property's not going to be changed by for the life of the rendered page, then there's no reason to define a cache variable.
您需要考虑您的测试包含少于 10 个 div 或其他 html 元素。像第一个示例那样编写代码的原因是为了使选择器更快，但会增加额外方法调用的成本。通常情况下，选择器应该是两者中更昂贵的一个，因此收益会超过损失，但对于这么小的 DOM，无论你如何编写它，选择器都会非常便宜。
人们经常犯这样的错误：没有记住更复杂和更大的 DOM 会改变代码的瓶颈。我认为 jsperf 应该对此有某种警告。
You need to consider that your test contains less than 10 divs or other html elements. The reason to write code like in the first example is to make the selector faster, but with the cost of additional method calls. Normaly the selector should be the more expensive of the two by far so the the gain would outweight the loss but with a DOM this small the selector will be very cheap no matter how you write it.
People often make the misstake of not remembering that a more complex and large DOM will change the bottlenecks of the code. I think jsperf should have some kind of warning about this.
我认为这是因为在“创建更多 jquery 对象”中，jQuery 可以直接使用最近的 API，
而在“较少 jquery”的情况下，您必须始终验证找到的元素是否位于 #appRoot 下，这需要更多时间。
这是使用 document 作为 appRoot 的另一个测试，它似乎在第二次运行时缩小了一点差距：
I think it is because the in "more jquery objects created", jQuery can make a direct use of the recent API
in the other case with "less jquery" you have to always verify that the element found are under #appRoot which takes more time.
Here is another test using document as appRoot which seems to close the gap a little on the second run: http://jsperf.com/minimize-jquery-object-creation/6