我正在浏览 js-perf 测试用例，发现了这个http://jsperf.com/pre-allocated-arrays-2/2。
结果 Array(100000) 比 Array(99999) 快。为什么会这样？
编辑：
我怀疑在执行时创建数组时是否遵循任何特定算法。即使我执行 99 与 100。100 在我的浏览器中速度更快。为了了解该算法（如果有的话），我发布了这个问题
浏览器：Chrome 30.0.15 操作系统：Mac OSX
问问题
359 次
5 回答
5
于 2013-10-10T10:27:03.943 回答
3
它在技术上并不快。只是你的测试结果就是这样出来的。
我也进行了测试，Array(99999) 比 Array(100000) 快 0.11%。在测试时再次运行它而不做任何事情。顺便说一句，有一个近似值 - 当我运行它时，它有 +/- 0.20% .. 这就是为什么它可能需要稍微大一点的跑得更快。
于 2013-10-10T10:23:21.093 回答
3
这个谜团与垃圾收集有关。
运行第一个测试会产生垃圾——事实上很多——所以垃圾收集器一定会在某个时候运行，从而减慢执行速度。
第二个测试将受到第一个测试中产生的垃圾的影响，这使得它比第一个测试更慢。
尝试交换测试，您会发现它是第一个获胜的：问题不在于数组大小，而在于测试顺序。
我们在这里看到了由 jsperf 引起的偏差之一，其结果应始终谨慎使用。
我在这里颠倒了测试顺序：http:
//jsperf.com/pre-allocated-arrays-2/5
我们可以看到“100K 比 100K-1 快”......前提是它位于第一位。
于 2013-10-10T10:45:58.397 回答
1
某些实现（尤其是 Safari 的 Nitro）在使用 length 调用 Array 构造函数时会预先分配内存，而其他实现则不会。可能 100k 是他们切换到不同行为的任意选择的限制。
于 2013-10-10T10:25:38.660 回答
1
您的答案在测试结构中。虽然它是一个黑盒，但我不能说为什么会这样，但在 javascript 中，第一个代码会更快。
我使用了那个测试系统并得到了结果：
- 如您所见，第二个代码较慢。作为结论 - 它要么是不稳定的测试系统，要么是没有足够的迭代来评估有意义的执行时间值。另请注意，尽管我的浏览器不是 Chrome，但如果原因在 js 内部，这无关紧要（虽然我的结果很明显）
于 2013-10-10T10:28:10.100 回答