blocks|key|183470|text|Chrome59更新:正如我在下面的答案中预测的那样，使用新的优化编译器，bind不再变慢。下面是包含详细信息的代码：https://codereview.chromium.org/2916063002/|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|183471|大多数时候，这都无关紧要。|183472|除非您正在创建一个.bind是瓶颈的应用程序，否则我不会费心的。在大多数情况下，可读性比纯粹的性能更重要。我认为使用原生.bind通常会提供更具可读性和可维护性的代码--这是一个很大的优势。|style|CODE|183473|然而，是的，当它很重要的时候-+.bind更慢|183474|是的，.bind比闭包慢得多--至少在Chrome中是这样，至少在目前v8中是这样实现的。我个人有时不得不切换到Node.JS来解决性能问题(更普遍的情况是，闭包在性能密集型情况下会比较慢)。|183475|为什么？因为与使用.call或.apply将一个函数包装成另一个函数相比，.bind算法要复杂得多。(有趣的是，它还返回一个toString设置为本机函数的函数)。|183476|从规范的角度和从实现的角度来看，有两种方法来看待这一点。让我们同时观察这两种情况。|183477|首先，让我们使用look+at+the+bind+algorithm+defined+in+the+specification|183478|183479|blockquote|183480|183481|将exception.|183482|Let设为this值。|unordered-list-item|183483|如果IsCallable(|ordered-list-item|183484|)为false，则抛出一个TypeError+|183485|A为thisArg+(arg1，arg2等)之后提供的所有参数值的新(可能为空)内部列表。|183486|183487|183488|..。|183489|(21.调用F的[DefineOwnProperty]内部方法，参数为"+arguments“、PropertyDescriptor+{[Get]：thrower、[Set]：thrower、[Enumerable]：false、[Configurable]：false}和false。|183490|(22.返回F。|183491|看起来相当复杂，不仅仅是一个总结。|183492|其次，让我们来看看how+it's+implemented+in+Chrome。|183493|让我们检查一下v8+(chrome+JavaScript+engine)源代码中的FunctionBind：|183494|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+(%25_IsConstructCall())+{
++++++return+%25NewObjectFromBound(boundFunction);
++++}
++++var+bindings+=+%25BoundFunctionGetBindings(boundFunction);

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

++%25FunctionRemovePrototype(boundFunction);
++var+new_length+=+0;
++if+(%25_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+=+%25_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+=+%25FunctionBindArguments(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;|code-block|syntax|javascript|183495|我们可以在实现中看到一堆昂贵的东西。即%25_IsConstructCall()。这当然是遵守规范所必需的-但在许多情况下，它也比简单的包装慢。|183496|183497|另一方面，调用.bind也略有不同，规范注释“使用Function.prototype.bind创建的函数对象没有原型属性或[代码]、[FormalParameters]和[作用域]内部属性”|183498|entityMap|0|LINK|mutability|MUTABLE|url|https://codereview.chromium.org/2916063002/|1|http://es5.github.io/#x15.3.4.5|2|https://code.google.com/p/v8/source/browse/trunk/src/v8natives.js#1727|3^0|1N|17|0|0|0|9|5|1O|5|0|G|5|0|3|5|Z|2|0|9|5|F|6|11|5|0|0|8|1J|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|9|U|2|0|15|C|15|C|3|0|0|J|J|0|0|7|5|0^^$0|@$1|2|3|4|5|6|7|2A|8|@]|9|@$A|2B|B|2C|1|2D]]|C|$]]|$1|D|3|E|5|6|7|2E|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|2F|8|@$A|2G|B|2H|H|I]|$A|2I|B|2J|H|I]]|9|@]|C|$]]|$1|J|3|K|5|6|7|2K|8|@$A|2L|B|2M|H|I]]|9|@]|C|$]]|$1|L|3|M|5|6|7|2N|8|@$A|2O|B|2P|H|I]|$A|2Q|B|2R|H|I]]|9|@]|C|$]]|$1|N|3|O|5|6|7|2S|8|@$A|2T|B|2U|H|I]|$A|2V|B|2W|H|I]|$A|2X|B|2Y|H|I]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|2Z|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|30|8|@]|9|@$A|31|B|32|1|33]]|C|$]]|$1|T|3|-4|5|6|7|34|8|@]|9|@]|C|$]]|$1|U|3|-4|5|V|7|35|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|36|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|37|8|@]|9|@]|C|$]]|$1|Z|3|10|5|11|7|38|8|@]|9|@]|C|$]]|$1|12|3|13|5|14|7|39|8|@]|9|@]|C|$]]|$1|15|3|16|5|6|7|3A|8|@]|9|@]|C|$]]|$1|17|3|18|5|14|7|3B|8|@]|9|@]|C|$]]|$1|19|3|-4|5|6|7|3C|8|@]|9|@]|C|$]]|$1|1A|3|-4|5|6|7|3D|8|@]|9|@]|C|$]]|$1|1B|3|1C|5|6|7|3E|8|@]|9|@]|C|$]]|$1|1D|3|1E|5|6|7|3F|8|@]|9|@]|C|$]]|$1|1F|3|1G|5|6|7|3G|8|@]|9|@]|C|$]]|$1|1H|3|1I|5|6|7|3H|8|@]|9|@]|C|$]]|$1|1J|3|1K|5|6|7|3I|8|@]|9|@$A|3J|B|3K|1|3L]]|C|$]]|$1|1L|3|1M|5|6|7|3M|8|@$A|3N|B|3O|H|I]]|9|@$A|3P|B|3Q|1|3R]]|C|$]]|$1|1N|3|1O|5|1P|7|3S|8|@]|9|@]|C|$1Q|1R]]|$1|1S|3|1T|5|6|7|3T|8|@$A|3U|B|3V|H|I]]|9|@]|C|$]]|$1|1U|3|-4|5|6|7|3W|8|@]|9|@]|C|$]]|$1|1V|3|1W|5|6|7|3X|8|@$A|3Y|B|3Z|H|I]]|9|@]|C|$]]|$1|1X|3|-4|5|6|7|40|8|@]|9|@]|C|$]]]|1Y|$1Z|$5|20|21|22|C|$23|24]]|25|$5|20|21|22|C|$23|26]]|27|$5|20|21|22|C|$23|28]]|29|$5|20|21|22|C|$23|28]]]]

<p>Chrome 59 update: As I predicted in the answer below bind is no longer slower with the new optimizing compiler. Here's the code with details: <a href="https://codereview.chromium.org/2916063002/" rel="noreferrer">https://codereview.chromium.org/2916063002/</a></p>
<h2>Most of the time it does not matter.</h2>
<p>Unless you're creating an application where <code>.bind</code> is the bottleneck I wouldn't bother. Readability is much more important than sheer performance in most cases. I think that using native <code>.bind</code> usually provides for more readable and maintainable code - which is a big plus.</p>
<h2>However yes, when it matters -  <code>.bind</code> is slower</h2>
<p>Yes, <code>.bind</code> is considerably slower than a closure - at least in Chrome, at least in the current way it's implemented in <code>v8</code>. I've personally had to switch in Node.JS for performance issues some times (more generally, closures are kind of slow in performance intensive situations).</p>
<p>Why? Because the <code>.bind</code> algorithm is a lot more complicated than wrapping a function with another function and using <code>.call</code> or <code>.apply</code>. (Fun fact, it also returns a function with toString set to [native function]).</p>
<p>There are two ways to look at this, from the specification point of view, and from the implementation point of view. Let's observe both.</p>
<h3>First, let's <a href="http://es5.github.io/#x15.3.4.5" rel="noreferrer">look at the bind algorithm defined in the specification</a>:</h3>
<blockquote>
<ol>
<li>Let Target be the this value.</li>
<li>If IsCallable(Target) is false, throw a TypeError exception.</li>
<li>Let A be a new (possibly empty) internal list of all of the argument values provided after thisArg (arg1, arg2 etc), in order.</li>
</ol>
<p>...</p>
<p>(21. Call the [[DefineOwnProperty]] internal method of F with arguments &quot;arguments&quot;, PropertyDescriptor {[[Get]]: thrower, [[Set]]: thrower, [[Enumerable]]: false, [[Configurable]]: false}, and false.</p>
<p>(22. Return F.</p>
</blockquote>
<p>Seems pretty complicated, a lot more than just a wrap.</p>
<h3>Second , let's see <a href="https://code.google.com/p/v8/source/browse/trunk/src/v8natives.js#1727" rel="noreferrer">how it's implemented in Chrome</a>.</h3>
<p>Let's check <a href="https://code.google.com/p/v8/source/browse/trunk/src/v8natives.js#1727" rel="noreferrer"><code>FunctionBind</code></a> in the v8 (chrome JavaScript engine) source code:</p>
<pre><code>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.
    &quot;use strict&quot;;
    // 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 &lt; bound_argc; i++) {
      argv[i] = bindings[i + 2];
    }
    for (var j = 0; j &lt; 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) == &quot;Function&quot;) {
    // Function or FunctionProxy.
    var old_length = this.length;
    // FunctionProxies might provide a non-UInt32 value. If so, ignore it.
    if ((typeof old_length === &quot;number&quot;) &amp;&amp;
        ((old_length &gt;&gt;&gt; 0) === old_length)) {
      var argc = %_ArgumentsLength();
      if (argc &gt; 0) argc--;  // Don't count the thisArg as parameter.
      new_length = old_length - argc;
      if (new_length &lt; 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;
</code></pre>
<p>We can see a bunch of expensive things here in the implementation. Namely <code>%_IsConstructCall()</code>. This is of course needed to abide to the specification - but it also makes it slower than a simple wrap in many cases.</p>
<hr />
<p>On another note, calling <code>.bind</code> is also slightly different, the spec notes &quot;Function objects created using Function.prototype.bind do not have a prototype property or the [[Code]], [[FormalParameters]], and [[Scope]] internal properties&quot;</p>


blocks|key|183518|text|我只想在这里给出一点观点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|183519|请注意，虽然bind()**ing很慢，但调用**绑定的函数并不慢！|offset|length|style|BOLD|CODE|183520|我在Linux上的Firefox+76.0中的测试代码如下：|183521|​|183522|//Set+it+up.
q+=+function(r,+s)+{

};
r+=+{};
s+=+{};
a+=+[];
for+(let+n+=+0;+n+<+1000000;+%2B%2Bn)+{
++//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);|code-block|syntax|javascript|183523|183524|因此，虽然.bind()ing确实比不绑定要慢大约2倍(我也做了测试)，但上面的代码对于所有3种情况(绑定0、1或2个变量)都需要相同的时间。|183525|183526|就我个人而言，我并不关心.bind()在我目前的用例中是否很慢，我关心的是一旦这些变量已经绑定到函数上，被调用的代码的性能。|183527|entityMap^0|0|6|8|H|4|6|6|0|0|0|0|0|5|7|0|0|C|7|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@$D|11|E|12|F|G]|$D|13|E|14|F|G]|$D|15|E|16|F|H]]|9|@]|A|$]]|$1|I|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|19|8|@]|9|@]|A|$P|Q]]|$1|R|3|L|5|6|7|1A|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1B|8|@$D|1C|E|1D|F|H]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1F|8|@$D|1G|E|1H|F|H]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|Y|$]]

<p>I just want to give a little bit of perspective here:</p>

<p>Note that while <strong><code>bind()</code>ing</strong> is slow, <strong>calling</strong> the functions once bound is not!</p>

<p>My test code in Firefox 76.0 on Linux:</p>

<p><div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="false">
<div class="snippet-code">
<pre class="snippet-code-js lang-js prettyprint-override"><code>//Set it up.
q = function(r, s) {

};
r = {};
s = {};
a = [];
for (let n = 0; n &lt; 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);</code></pre>
</div>
</div>
</p>

<p>So while it is true that <code>.bind()</code>ing can be some ~2X slower than not binding (I tested that too), the above code takes the same amount of time for all 3 cases (binding 0, 1, or 2 variables).</p>

<hr>

<p>Personally, I don't care if the <code>.bind()</code>ing is slow in my current use case, I care about the performance of the code being called once those variables are already bound to the functions.</p>


<p>A previous poster asked <a href="https://stackoverflow.com/questions/6397096/function-bind-vs-closure-in-javascript-how-to-choose">Function.bind vs Closure in Javascript : how to choose?</a></p>

<p>and received this answer in part, which seems to indicate bind should be faster than a closure:</p>

<blockquote>
  <p>Scope traversal means, when you are reaching to grab a value
  (variable,object) that exists in a different scope, therefore
  additional overhead is added (code becomes slower to execute).</p>
  
  <p>Using bind, you 're calling a function with an existing scope, so that
  scope traversal does not take place.</p>
</blockquote>

<p>Two jsperfs suggest that bind is actually much, much slower than a <a href="http://jsperf.com/bind-vs-closure-performace" rel="noreferrer">closure</a>.</p>

<p>This was posted as a comment to the above</p>

<p>And, I decided to write <a href="http://jsperf.com/simple-null-bind-vs-closure" rel="noreferrer">my own jsperf</a></p>

<p>So why is bind so much slower (70+% on chromium)?</p>

<p>Since it is not faster and closures can serve the same purpose, should bind be avoided?</p>


Why is bind slower than a closure?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

之前的一篇帖子问并收到了这个答案的一部分，这似乎表明绑定应该比闭包更快：作用域遍历意味着，当您试图获取存在于不同作用域中的值(变量、对象)时，因此会增加额外的开销(代码的执行速度会变慢)。使用bind，您将调用一个具有现有作用域的函数，因此不会发生作用域遍历。两个jsperfs表明bind实际上比慢得多。这是作为对上面...

问为什么绑定比闭包慢？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么绑定比闭包慢？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么绑定比闭包慢？
EN