JavaScript 中读取数组的“length”属性真的那么昂贵吗？

Question

我一直认为在 JavaScript 中缓存数组的长度是一个好主意（特别是在 for 循环的情况下），因为计算数组长度的成本很高。

示例

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

// vs

for (var i = 0, arrLength = arr.length; i < arrLength; i++) { }

但是，我认为也许 length 属性仅在创建和更改数组时更新。因此，与读取存储在变量中的操作相比，读取它不应该是太昂贵的操作（与其他语言中可能需要在内存中查找以找到某些内容的结尾的其他方法相反，例如 strlen( ) 在 C) 中。

我有两个问题。我也对它的工作原理很感兴趣，所以请不要用过早的优化棒来打击我。

假设浏览器中的 JavaScript 引擎。

1. 在 JavaScript 中缓存数组的 length 属性有什么好处吗？与读取对象的属性相比，读取局部变量是否涉及更多内容？
2. length 属性是否在创建时以及在不返回新数组的 shift() 和 pop() 类型方法上进行了简单更改，否则简单地存储为整数？

Answer 1

好吧，我会说它很贵，但后来我写了一个小测试@ jsperf.com 令我惊讶的是，在 Chrome 中使用 i 实际上更快，而在 FF(4) 中这并不重要。

我怀疑长度存储为整数（Uint32）。来自 ECMA 规范（262 第 5 版，第 121 页）：

每个数组对象都有一个
length 属性，其值始终是小于 2³² 的非负整数。长度属性的值为
数字大于名称
每个名称为数组的属性
指数;每当数组的属性
对象被创建或更改，其他
属性根据需要进行调整
来维持这个不变量。
具体来说，每当财产
添加的名称是数组索引，
长度属性改变，如果
必要的，比
该数组索引的数值；和
每当 length 属性为
已更改，名称为的每个属性
其值不是的数组索引
小于新长度
自动删除。这个约束
仅适用于自己的财产
数组对象，不受
长度或数组索引属性
可能继承自其原型

唷！我不知道我是否习惯了这样的语言......

最后，我们总是有我们的好旧落后的浏览器。在 IE (9,8,7) 中，缓存长度确实更快。我说，这是不使用 IE 的众多原因之一。

Answer 2

TL;DR：

据我所知，似乎数组的长度是在内部缓存的（至少在 V8 中）..

（详细信息？请继续阅读:)）

所以，这个问题已经解决了在我的脑海中思考了几次，我决定找到问题的根源（至少在一个实现中）。

挖掘 V8 源代码产生了 JSArray 类。

// The JSArray describes JavaScript Arrays
//  Such an array can be in one of two modes:
//    - fast, backing storage is a FixedArray and length <= elements.length();
//       Please note: push and pop can be used to grow and shrink the array.
//    - slow, backing storage is a HashTable with numbers as keys.

我假设数组元素的类型决定了它是快还是慢。我在 set_has_fast_elements (set_bit_field2(bit_field2() | (1 << kHasFastElements))) 中设置了一个位标志，这就是我想的地方当我在谷歌代码中查找并且本地没有源代码时，我会画出挖掘线。

现在，似乎任何时间任何对数组（它是 JSObject 的子类）进行操作，调用 NormalizeElements()，执行以下操作：

// Compute the effective length.
  int length = IsJSArray() ?
      Smi::cast(JSArray::cast(this)->length())->value() :
      array->length();

因此，在回答您的问题时：

1. Chrome（或使用 V8 的其他浏览器）似乎没有任何缓存优势length 属性数组的（除非你正在做一些奇怪的事情，这会迫使它变慢（我不确定这些条件是什么）） - 话虽如此，我很可能会继续缓存 < code>length 直到我有机会了解所有操作系统浏览器实现；）
2. length 属性似乎在any之后发生了改变> 对对象的操作

编辑：

顺便说一句，看起来一个“空”数组实际上被分配了 4 个元素：

// Number of element slots to pre-allocate for an empty array.
static const int kPreallocatedArrayElements = 4;

我不确定一旦超出界限数组会增长多少个元素 - 我没有挖那么深： ）

Answer 3

另一组性能测试。该循环是通过一个空循环对一百万个随机数的数组完成的。

在 Chrome 中，具有缓存和非缓存长度的循环的时钟时间几乎相同，因此我猜测它是 V8优化缓存长度。

在 Safari 和 Firefox 中，缓存长度始终比非缓存版本快 2 倍左右。

Answer 4

本文通过向 IRHydra 询问生成的代码来研究 V8 和 Chrome 中的自动缓存：

格林奇如何窃取 array.length 访问权限作者：维亚切斯拉夫·叶戈罗夫

他发现在某些条件下手动缓存.length实际上增加了开销而不是提高性能！

但无论如何，这种微观优化不太可能为您的用户带来任何显着的收益。为了他们的利益，也为了您的利益，请重点关注易于阅读的代码，并在代码中使用良好的数据结构和算法！

避免过早优化：专注于优雅的代码，直到出现性能问题。然后，通过分析找出瓶颈，然后优化那部分代码。

Answer 5

请注意：

在某些浏览器上（我在 Safari、IE 和 Opera 中注意到了这一点），您可以通过缓存 for 循环声明内的长度来提高速度：

var j;
for (var i = 0, len = arr.length; i < len; i++) {
  j = arr[i];
}

我将上面的 @KooiInc 的 jsperf 测试编辑为 添加此案例。

Answer 6

请注意不要假设这对于所有可迭代集合都是如此。例如，缓存 HTMLCollection 的长度在 Chrome（版本 41）中快了 65%，在 Firefox（版本 36）中快了 35%。

http://jsperf.com/array-length-in-loop-dom