为什么绑定比关闭慢？

Question 1

先前的发帖人在Javascript中问Function.bind vs Closure：如何选择？

并部分地收到了这个答案，这似乎表明bind应该比闭包更快：

范围遍历意味着，当您要获取存在于另一个范围中的值（变量，对象）时，因此会增加额外的开销（代码执行起来会变慢）。

使用bind时，您正在使用现有范围调用函数，因此不会发生范围遍历。

两个jsperfs表示bind实际上比闭包要慢得多。

这是对以上内容的评论

而且，我决定编写自己的jsperf

那么，为什么结合速度这么慢（铬含量超过70％）？

由于速度不是更快，并且闭包可以达到相同的目的，是否应避免绑定？

Question 2

Chrome 59更新：正如我在下面的回答中所预测的那样，使用新的优化编译器后，绑定不再变慢。这是带有详细信息的代码：https : //codereview.chromium.org/2916063002/

大多数时候都没有关系。

除非您创建一个应用程序，否则.bind瓶颈就不会困扰我。在大多数情况下，可读性比纯粹的性能更为重要。我认为使用本机.bind通常会提供更具可读性和可维护性的代码-这是一大优势。

但是，是的，重要的`.bind`是- 速度较慢

是的，.bind它比闭包要慢得多-至少在Chrome中，至少是在中当前实现的方式中v8。我个人有时不得不切换到Node.JS来解决性能问题（更一般地说，在性能密集型情况下，闭包有点慢）。

为什么？因为该.bind算法比使用另一个函数包装一个函数并使用.call或复杂得多.apply。（有趣的是，它还会返回一个toString设置为[native function]的函数）。

从规范的角度和从实现的角度来看，有两种方法可以查看。让我们观察两者。

首先，让我们看一下规范中定义的绑定算法：

令Target为该值。

如果IsCallable（Target）为false，则抛出TypeError异常。

令A为按顺序在thisArg（arg1，arg2等）之后提供的所有参数值的新内部列表（可能为空）。

...

（21.用参数“参数”调用F的[[DefineOwnProperty]]内部方法，PropertyDescriptor {[[Get]]：thrower，[[Set]]：thrower，[[Enumerable]]：false，[[Configurable] ]：false}和false。

（22.返回F。

看起来非常复杂，不只是包装。

其次，让我们看看它如何在Chrome中实现。

让我们检查FunctionBind一下v8（chrome JavaScript引擎）源代码：

function FunctionBind(this_arg) { // Length is 1.
  if (!IS_SPEC_FUNCTION(this)) {
    throw new $TypeError('Bind must be called on a function');
  }
  var boundFunction = function () {
    // Poison .arguments and .caller, but is otherwise not detectable.
    "use strict";
    // This function must not use any object literals (Object, Array, RegExp),
    // since the literals-array is being used to store the bound data.
    if (%_IsConstructCall()) {
      return %NewObjectFromBound(boundFunction);
    }
    var bindings = %BoundFunctionGetBindings(boundFunction);

    var argc = %_ArgumentsLength();
    if (argc == 0) {
      return %Apply(bindings[0], bindings[1], bindings, 2, bindings.length - 2);
    }
    if (bindings.length === 2) {
      return %Apply(bindings[0], bindings[1], arguments, 0, argc);
    }
    var bound_argc = bindings.length - 2;
    var argv = new InternalArray(bound_argc + argc);
    for (var i = 0; i < bound_argc; i++) {
      argv[i] = bindings[i + 2];
    }
    for (var j = 0; j < argc; j++) {
      argv[i++] = %_Arguments(j);
    }
    return %Apply(bindings[0], bindings[1], argv, 0, bound_argc + argc);
  };

  %FunctionRemovePrototype(boundFunction);
  var new_length = 0;
  if (%_ClassOf(this) == "Function") {
    // Function or FunctionProxy.
    var old_length = this.length;
    // FunctionProxies might provide a non-UInt32 value. If so, ignore it.
    if ((typeof old_length === "number") &&
        ((old_length >>> 0) === old_length)) {
      var argc = %_ArgumentsLength();
      if (argc > 0) argc--;  // Don't count the thisArg as parameter.
      new_length = old_length - argc;
      if (new_length < 0) new_length = 0;
    }
  }
  // This runtime function finds any remaining arguments on the stack,
  // so we don't pass the arguments object.
  var result = %FunctionBindArguments(boundFunction, this,
                                      this_arg, new_length);

  // We already have caller and arguments properties on functions,
  // which are non-configurable. It therefore makes no sence to
  // try to redefine these as defined by the spec. The spec says
  // that bind should make these throw a TypeError if get or set
  // is called and make them non-enumerable and non-configurable.
  // To be consistent with our normal functions we leave this as it is.
  // TODO(lrn): Do set these to be thrower.
  return result;

在执行过程中，我们可以看到很多昂贵的东西。即%_IsConstructCall()。当然，必须遵守规范-但在许多情况下，它也比简单包装慢。

另一个注意，调用.bind也略有不同，规范说明“使用Function.prototype.bind创建的函数对象没有原型属性，或者内部没有[[Code]]，[[FormalParameters]]和[[Scope]]内部属性”

Question 3

我只想在这里给出一些观点：

请注意，尽管bind()ing很慢，但一旦绑定就调用函数不是！

我在Linux上的Firefox 76.0中的测试代码：

//Set it up.
q = function(r, s) {

};
r = {};
s = {};
a = [];
for (let n = 0; n < 1000000; ++n) {
  //Tried all 3 of these.
  //a.push(q);
  //a.push(q.bind(r));
  a.push(q.bind(r, s));
}

//Performance-testing.
s = performance.now();
for (let x of a) {
  x();
}
e = performance.now();
document.body.innerHTML = (e - s);

展开摘要

因此，尽管.bind()ing确实比不绑定慢大约2倍（我也测试了），但是上述代码在所有3种情况下（绑定0、1或2个变量）花费的时间相同。

就我个人而言，我不在乎.bind()在当前使用情况下ing是否缓慢，我关心的是一旦这些变量已经绑定到函数上就调用了代码。

为什么绑定比关闭慢？

大多数时候都没有关系。

但是，是的，重要的.bind是- 速度较慢

首先，让我们看一下规范中定义的绑定算法：

其次，让我们看看它如何在Chrome中实现。

但是，是的，重要的`.bind`是- 速度较慢