为什么Array（99999）比Array（100000）慢

Question

我正在浏览js-perf测试用例并找到了http://jsperf.com/pre-allocated-arrays-2/2。

结果数组（100000）比数组（99999）快。为什么这样？

编辑：

我怀疑是在执行时创建数组时是否遵循任何特定算法。即使我执行99 vs 100.我的浏览器速度更快100。为了了解算法（如果有的话），我发布了这个问题

浏览器：Chrome 30.0.15 操作系统：Mac OSX

Answer 1

此工具不会给％100准确的结果，所以它是正常的Array（100000）比Array（99999）快。

我的测试： http://jsperf.com/ideaferid

Answer 2

技术上并不快。你的测试结果就是这样出来的。

我也运行了测试，Array（99999）比Array（100000）快了0.11％。在测试时不再做任何事情再次运行它。顺便说一下有一个近似值 - 当我运行时它有+/- 0.20％..这就是为什么它可以采取稍大一点运行得更快。

Answer 3

这个谜团与垃圾收集有关 运行第一个测试会产生垃圾 - 事实上很多 - 因此垃圾收集器必然会在某个时间运行，从而减慢执行速度。
第二个测试将受到第一个测试中创建的垃圾的影响，这使得它比第一个测试更容易 更慢。
尝试交换测试，你会发现它是第一个获胜的：问题不在于数组大小，而在于测试顺序。

我们在这里看到了jsperf引起的偏差之一，其结果应始终与预防措施一起使用。

我在这里颠倒了测试顺序：
http://jsperf.com/pre-allocated-arrays-2/5
我们可以看到“100K快于100K-1”......只要它处于第一位置。

Answer 4

某些实现（特别是Safari的Nitro）会在Array constructor is called with a length时预先分配内存，而其他实现则不会。可能100k是一些任意选择的限制，在这种限制下他们会切换到不同的行为。

Answer 5

你的答案在于测试结构。虽然它是一个黑盒子，我不能说为什么会这样，但在javascript中第一个代码会更快。

我已经使用了那个测试系统并得到了结果：

- 你可以看到，第二个代码更慢。作为结论 - 它要么是不稳定的测试系统，要么是没有足够的迭代来评估有意义的执行时间值。另请注意，尽管我的浏览器不在Chrome中，如果原因在js内，这应该不重要（虽然我的结果很明显）