Javascript For循环条件缓存答案

【问题标题】：Javascript For-Loop Condition CachingJavascript For循环条件缓存
【发布时间】：2014-11-07 03:01:27
【问题描述】：

我已经整理了一个 jsperf 测试，该测试比较了在缓存数组长度条件与不缓存的情况下迭代数组的 for 循环。我认为之前缓存变量以避免每次迭代重新计算数组长度会更快，但 jsperf 测试另有说明。有人可以解释这是为什么吗？我还认为在 for 循环的初始化中包含数组长度变量定义（缓存时）会减少时间，因为解析不需要两次查找“var”关键字，但这似乎也不是案例。

没有缓存的例子：

for(var i = 0; i < testArray.length; i++){
   //
}

缓存示例

var len = testArray.length;
for(var i = 0; i < len; i++){
  //
}

在 for 循环初始化中定义缓存变量的示例

for(var i = 0, len=testArray.length; i < len; i++){
   //
}

http://jsperf.com/for-loop-condition-caching

【问题讨论】：

长度实际上不是在访问时计算，它是一个静态值，当数组发生变异时会更新。而今天的引擎可能会优化正常的for 循环。
在您的 jsperf 示例中，Console.Log 可能不是循环体中最好的东西。
摆脱console.log:jsperf.com/for-loop-condition-caching/2性能基本一样。正如其他人所说，这可能已经被浏览器优化了。
Loop through an array in JavaScript的可能重复

标签： javascript performance

【解决方案1】：

谁能解释这是为什么？

这种优化和案例非常普遍，因此现代 JavaScript 引擎会自动为您执行这种优化。

一些注意事项：

迭代NodeList时不是这样的（比如querySelectorAll的结果
无论如何，这对于大多数代码路径来说都是一种过度的微优化，通常循环体比这种比较花费更多的时间。

【讨论】：

+1: 50,000 console.log 这是 OPs 测试中的瓶颈，而不是两个数字的比较。
是的，这只是放在循环中的任意东西，我没有意识到它会产生如此大的影响。感谢更新 jsperf
@ejfrancis 基准测试代码很难，在微基准测试中正确完成它更难。即使在那之后你也不确定它是否说了什么有意义的东西。

【解决方案2】：

您发布的场景的性能取决于 JS 引擎的优化器的智能程度。当您使用该变量时，具有非常转储优化器（或根本没有优化器）的引擎可能会更快，但您甚至不能依赖它。毕竟，长度的类型是众所周知的，而变量可以是任何东西并且可能需要额外的检查。给定一个完美的优化器，所有三个示例都应该具有相同的性能。由于您的示例非常简单，因此现代引擎应该很快就会达到这一点。

【讨论】：