为什么for-in的javascript速度很慢？

Question

我已经在很多地方读到了for-in循环比循环遍历数组要慢...尽管我了解到，与在场景背后进行迭代以遍历对象的键相比，在sizeof（type）块中前进实际上是毫不费力的，我仍然很好奇，确切的原因是这么慢...

是否必须执行反向哈希函数才能获取密钥，而这个过程很慢？

Answer 1

对于任何特定引擎，对此的真正答案很可能取决于该引擎的实现。 （如果有的话，差异的大小也会如此。）

但是，有不变量。 例如，考虑：

var obj = {a: "alpha", b: "beta"};
var name;
for (name in obj) {
    console.log(obj[name]);
}

var arr = ["alpha", "beta"];
var index;
for (index = 0; index < arr.length; ++index) {
    console.log(arr[index]);
}

对于obj ，引擎必须使用一种机制来跟踪已迭代的属性和尚未迭代的属性，并过滤掉不可枚举的属性。 例如，幕后有某种迭代器对象（以及规范的定义方式，很可能是一个临时数组）。

在arr的情况下，它不是； 您可以以非常简单，有效的方式在代码中进行处理。

每个循环的块内容相同：在对象上进行属性查找。 （在后一种情况下，理论上也有数字到字符串的转换。）

因此，我希望对此的唯一非特定于实现的答案是：额外的开销。

Answer 2

for..each循环使用迭代器和生成器 。

迭代器是具有next()方法的对象。 Generator是一个包含yield()表达式的工厂函数。 两种构造都比整数索引变量复杂。

在典型的for(var i = 0; i < arr.length; i++)循环中，几乎在所有迭代中执行的两个命令是i++和i < arr 。 可以说这比进行函数调用（ next()或yield() ）快得多。

此外，循环启动（ var i = 0 ）也比使用next()方法创建迭代器对象或调用生成器创建迭代器要快。 但是，它高度依赖于实现，并且Javascript引擎的创建者会尽最大努力来加速这种常用的语言功能。

我会说这种差异非常小，以至于我可能想花时间优化代码的其他部分。 语法的选择应该考虑代码的可读性和可维护性，而不是性能，这是因为性能增益太小而增加复杂性。 话虽如此，请使用对您和其他在您变得富有和出名之后维护代码的开发人员来说更有意义的语法！ ;）