Function.prototype.bind() 会一直很慢吗？

Question

我正在编写一个开源 javascript 库，并且我大量使用.bind() 方法，因为我认为面向对象的代码看起来更清晰。 （值得商榷）

示例

A1：

var that = this;

setTimeout(function () {
    that.method();
}, 0);

对

B1：

setTimeout(this.method.bind(this), 0);

或者，更实用的代码部分

A2：

remoteDataSource.getData(function (a, b, c, d) {
     obj.dataGetter(a, b, c, d);
})

vs B2：

remoteDataSource.getData(obj/* or prototype */.dataGetter.bind(obj));

我在旧版浏览器中使用非原生 bind，一切都很完美，直到我打开 jsperf benchmark for bind。

使用bind 的代码看起来慢了 100 倍。现在，在重写我所有的库之前，我有一个问题要问那些熟悉 javascript 引擎的人：

作为新功能，bind 是否有可能得到优化 很快，还是因为 JavaScript 架构限制没有机会？

Answer 1

目前，在 2013 年末，最好的解决方案将是实现 Function.prototype.bind 的 手工制作 版本，并使用您自己的 javascript 代码覆盖供应商的“本机”（不是真正的本机）方法，或者使用你自己的myBind。

Function.prototype.apply 相当快，而数组切片、连接和移位很慢，因此如果bind 最好使用apply，或者尽量减少myBind 函数中的参数操作。这将使您没有参数预填充的功能。

所以我认为没有必要将所有内容重写为闭包（丑陋的var that = this;）。让 javascript 的功能特性获胜。

更多细节和工作代码示例在这里：

http://jsperf.com/function-bind-performance/4

http://jsperf.com/function-bind-performance/5

http://jsperf.com/bind-vs-emulate/4 .. 10.

总结：找到的解决方法还不错。勇敢地使用它们。如果您使用功能不全的bind，请不要离最初的概念太远，因为我没有发现它尚未在 C 中实现的原因。这是时间问题。

Answer 2

首先，修复jsperf http://jsperf.com/bind-vs-emulate/13。

=您不应在基准测试中重新创建静态函数。这是不现实的，因为在实际代码中静态函数只创建一次。

您可以看到var self = this 模式仍然快了大约 60%。但它需要将函数定义内联到可以从任何地方绑定的位置，因此具有更好的可维护性。

---

不，内置的绑定语义非常复杂。

当我绑定时，我只想要这个：

function bind(fn, ctx) {
    return function bound() {
        return fn.apply(ctx, arguments);
    };
}

如果我想预先应用参数或使用一些深层的构造函数黑魔法，我会想要一个完全不同的函数。我不知道为什么这些都包含在 bind 中。

顺便说一句，ES5 中引入的几乎所有东西都存在同样的问题，通过强制实现处理一些与实践中的任何人都不合理相关的理论边缘情况来惩罚常见情况。下一个语言版本继续沿同一路径前进。

模拟绑定甚至根本不尝试模拟绑定。即使你试图模仿它，你也无法 完全这样做是不公平的。

因此，在其他所有条件相同的情况下*，内置绑定不会比仅绑定的常识自定义绑定更快。

*在 JIT 中，用户代码与内置代码相比没有明显的劣势。事实上，SM 和 V8 都实现了许多内置功能 在 Javascript 中。