其他答案和评论提到两个循环之间的区别在于第一个循环比第二个循环多执行一次迭代。这是事实,但在一个增长到 25,000 个元素的数组中,多一次或少一次迭代只会产生微小的差异。作为一个大概的猜测,如果我们假设其增长的平均长度为 12,500,那么我们预期的差异应该约为 1/12,500,或仅为 0.008%。
这里的性能差异比一次额外迭代所解释的要大得多,并且该问题在演示文稿接近尾声时得到了解释。
this.primes
是一个连续的数组(每个元素都有一个值)并且元素都是数字。
JavaScript 引擎可以将这样的数组优化为实际数字的简单数组,而不是恰好包含数字但可能包含其他值或不包含值的对象数组。第一种格式的访问速度要快得多:它需要更少的代码,并且数组要小得多,因此它更适合缓存。但有些条件可能会阻止使用这种优化格式。
一种情况是某些数组元素丢失。例如:
let array = [];
a[0] = 10;
a[2] = 20;
现在的价值是多少a[1]
? It 没有价值。 (说它具有价值甚至是不正确的undefined
- 包含以下内容的数组元素undefined
值与完全缺失的数组元素不同。)
没有办法仅用数字来表示这一点,因此 JavaScript 引擎被迫使用优化程度较低的格式。如果a[1]
与其他两个元素一样包含一个数值,该数组可能会被优化为仅包含数字的数组。
数组被强制采用去优化格式的另一个原因可能是您尝试访问数组边界之外的元素,如演示中所述。
第一个循环与<=
尝试读取超出数组末尾的元素。该算法仍然可以正常工作,因为在最后一次额外迭代中:
-
this.primes[i]
评估为undefined
因为i
超出了数组末尾。
-
candidate % undefined
(对于任何值candidate
) 评估为NaN
.
-
NaN == 0
评估为false
.
- 因此,
return true
没有被执行。
所以就好像额外的迭代从未发生过——它对其余逻辑没有影响。该代码产生的结果与没有额外迭代的结果相同。
但为了到达那里,它尝试读取超出数组末尾的不存在的元素。这迫使阵列退出优化——或者至少在本次演讲时是这样。
第二个循环与<
仅读取数组中存在的元素,因此它允许优化数组和代码。
问题描述于第 90-91 页 https://v8-io12.appspot.com/#90演讲的内容,以及前后几页的相关讨论。
我碰巧参加了这次 Google I/O 演示,并随后与演讲者(V8 作者之一)进行了交谈。我一直在自己的代码中使用一种技术,该技术涉及读取数组末尾之后的内容,作为优化某个特定情况的误导性(事后看来)尝试。他证实,如果你试图甚至read超过数组末尾,它将阻止使用简单优化格式。
如果 V8 作者所说的仍然正确,那么读取超出数组末尾的内容将阻止其优化,并且必须回退到较慢的格式。
现在,V8 可能同时得到了改进,以有效地处理这种情况,或者其他 JavaScript 引擎会以不同的方式处理它。我不知道这方面的一种或另一种方式,但这种去优化正是演示文稿所讨论的内容。