'var _args = arguments' 作为优化缺陷

Question

不知道arguments

这样的用法

    var _args = arguments;
    arr.forEach(function (val, i) {
        arr[i] = _args[i]; 
    });

对优化造成不利影响。

严格来说它不符合任何these optimization killers但它不符合规则

Never use arguments directly without .length or [i]

要么。在这种情况下，低电平到底发生了什么？

JS内部是问题的主题，数组迭代的具体实现不是。

Answer 1

"Never use arguments without [i] or .length" 参数与性能的直接关系较少，而与 arguments 对象的 black-magic 有关。

不可能告诉你在所有实现中发生了什么，在所有JS引擎的所有版本中，因为它是implementation-specific.

它的接口有规则，但驱动接口的代码的实现没有规则。

参数（或任何别名）的定义行为本身会根据您是否处于严格模式而变化，因此性能考虑不仅取决于您是处于严格模式还是松散模式，还取决于引擎对两个代码路径的实现。

创建一个指向 arguments 的别名（不是从 arguments 构建的数组）确实没有多大帮助。它不会帮助人类维护它；它不会帮助大多数引擎运行它。它仍然会表现出与直接引用 arguments 相同的神奇行为（因此，具有相同的性能影响）（同样，根据严格或松散的操作而有所不同）。

这就是为什么如果你想对魔法元素（arguments、live NodeLists 等实例）做任何事情，你应该将它们的内容放在一个数组中，或者放在一个对象上。因为您每次访问这些魔法盒时都需要支付 accessing/modifying 个元素的价格。

唯一的方法是告诉每个引擎、每个 engine-version、每个浏览器、每个设备的成本是多少... ......就是在所有这些事情上测试它们，期望唯一一致的事实是数组内部的 accessing/modifying 元素将比神奇 accessing/modifying 内部的元素快得多 live-lists.

编辑

此外，在查看了您在评论中链接到的 Bluebird 维基部分后，black-magic 正是他们指的是，在给你的信息中。

function add (a, b) {
  return a + b;
}


function unsafeAdd (a, b) {
  arguments[1] = 12;
  return a + b;
}


function safeAdd (a, b) {
  "use strict";
  arguments[1] = 41;
  return a + b;
}


add(1, 2); // 3
unsafeAdd(1, 2); // 42
safeAdd(1, 2); // 3

这与速度提升 ("Optimization") 关系不大，更多的是为了防止愚蠢（或无意 side-effects 的聪明）。但是同样，只要看看 safeAdd 和 unsafeAdd 之间的行为差异，您就应该明白为什么性能也会发生变化。

'var _args = arguments' 作为优化缺陷

'var _args = arguments' as optimization flaw

javascript

v8

node.js

编辑