JS 预分配数组长度，到底是变慢还是变快？

在我的上一篇文章 JavaScript 在 V8 中的元素种类及性能优化 中写道：

V8 的类型转换只能通过格子向下过渡。一旦将单精度浮点数添加到 Smi 数组中，即使稍后用 Smi 覆盖浮点数，它也会被标记为 DOUBLE。类似地，一旦在数组中创建了一个洞，它将被永久标记为有洞 HOLEY，即使稍后填充它也是如此。

一旦数组被标记为有洞，它永远是有洞的 - 即使它被打包了！从那时起，数组上的任何操作都可能变慢。如果您计划在数组上执行大量操作，并且希望对这些操作进行优化，请避免在数组中创建空洞。V8 可以更有效地处理密集数组。

然后有人提出了一个疑问：

为什么先指定长度再初始化测试出来会快一点？

其实，两者相比只是“可能”变慢。

具体因素有很多，比如预分配一个很大的数组，这时可以变快，lodash 的 map 函数就是这么做的。因为初始化的时候分配完空间，就可以避免在数组空间不够用的时候反复的内存申请和 GC 操作。而 FAST_ELEMENTS 和 FAST_HOLEY_ELEMENTS 都不太慢，至少在所有元素中可以排到前二。

https://cs.chromium.org/chromium/src/v8/src/elements-kind.h?l=23

数组分配完成后默认是 FAST_HOLEY_SMI_ELEMENTS，当元素中添加了新的非 smi 值时，数据会进行类型转换。 --trace-elements-transitions 的输出：

  
  
elements transition [FAST_HOLEY_SMI_ELEMENTS -> FAST_HOLEY_ELEMENTS]

我写了一个性能测试，对于 HOLEY_ELEMENTS，读取的时候 HOLEY 慢很多，写入的时候性能一样。如果数组很大，预先分配大小后性能反而会提升。

https://jsperf.com/array-element-types-read

https://jsperf.com/array-element-types-write

还有一个重要的性能提示就是：避免读数超出数组的长度！这样 V8 会在原型链上去找这个属性。