admin管理员组

文章数量:1201370

I have written a very simple benchmark:

console.time('var');
for (var i = 0; i < 100000000; i++) {}
console.timeEnd('var')


console.time('let');
for (let i = 0; i < 100000000; i++) {}
console.timeEnd('let')

If you're running Chrome, you can try it here (since NodeJS and Chrome use the same JavaScript engine, albeit usually slightly different versions):

// Since Node runs code in a function wrapper with a different
// `this` than global code, do that:
(function() {
  console.time('var');
  for (var i = 0; i < 100000000; i++) {}
  console.timeEnd('var')


  console.time('let');
  for (let i = 0; i < 100000000; i++) {}
  console.timeEnd('let')
}).call({});

I have written a very simple benchmark:

console.time('var');
for (var i = 0; i < 100000000; i++) {}
console.timeEnd('var')


console.time('let');
for (let i = 0; i < 100000000; i++) {}
console.timeEnd('let')

If you're running Chrome, you can try it here (since NodeJS and Chrome use the same JavaScript engine, albeit usually slightly different versions):

// Since Node runs code in a function wrapper with a different
// `this` than global code, do that:
(function() {
  console.time('var');
  for (var i = 0; i < 100000000; i++) {}
  console.timeEnd('var')


  console.time('let');
  for (let i = 0; i < 100000000; i++) {}
  console.timeEnd('let')
}).call({});

And the results amaze me:

var: 89.162ms
let: 320.473ms

I have tested it in Node 4.0.0 && 5.0.0 && 6.0.0 and the proportion between var and let is the same for each node version.

Could someone please explain to me what is the reason behid this seemingly odd behaviour?

Share Improve this question edited Jun 13, 2016 at 15:06 T.J. Crowder 1.1m199 gold badges2k silver badges1.9k bronze badges asked Jun 13, 2016 at 14:53 Jan GrzJan Grz 1,47317 silver badges20 bronze badges 4
  • Comments are not for extended discussion; this conversation has been moved to chat. – George Stocker Commented Jun 15, 2016 at 10:14
  • 1 Issue on the V8 bug tracker: bugs.chromium.org/p/v8/issues/… – Jo Liss Commented Mar 14, 2017 at 17:59
  • 2 Yes, testing in Chrome 60 this issue seems to solved in Chrome so it should be solved in node soon. It was already solved in SpiderMonkey. It has yet to be solved for Safari Nitro as of May 9th 2017 – user128511 Commented May 9, 2017 at 3:20
  • In the meantime, let is faster in Chrome, on Node, even in IE 11. – Wolfgang Stengel Commented Feb 3, 2021 at 10:19
Add a comment  | 

2 Answers 2

Reset to default 18

A note from the future: these historical performance differences are no longer accurate or relevant, as modern engines can optimize let semantics by using var semantics when there are no observable differences in behavior. When there are observable differences, using the correct semantics makes little difference in performance since the relevant code is already asynchronous in nature.

Based on the difference between the mechanics of var vs. let, this discrepancy in runtime is due to the fact that var exists in the entire block scope of the anonymous function while let exists only within the loop and must be re-declared for each iteration.* see below Here's an example demonstrating this point:

(function() {
  for (var i = 0; i < 5; i++) {
    setTimeout(function() {
      console.log(`i: ${i} seconds`);
    }, i * 1000);
  }
  // 5, 5, 5, 5, 5


  for (let j = 0; j < 5; j++) {
    setTimeout(function() {
      console.log(`j: ${j} seconds`);
    }, 5000 + j * 1000);
  }
  // 0, 1, 2, 3, 4
}());

Notice that the i is shared across all iterations of the loop while let is not. Based on your benchmark, it appears that node.js just hasn't optimized scoping rules for let since it's much more recent and complicated than var is.

Elaboration

Here's a little layman explanation of let in for loops, for those who don't care to look into the admittedly dense specs, but are curious how let is re-declared for each iteration while still maintaining continuity.

But let can't possibly be re-declared for each iteration, because if you change it inside the loop, it propagates to the next iteration!

First here's an example that almost appears to validate this potential counter-argument:

(function() {
  for (let j = 0; j < 5; j++) {
    j++; // see how it skips 0, 2, and 4!?!?
    setTimeout(function() {
      console.log(`j: ${j} seconds`);
    }, j * 1000);
  }
}());

You are partially right, in that the changes respect the continuity of j. However, it is still re-declared for each iteration, as demonstrated by Babel:

"use strict";

(function () {
  var _loop = function _loop(_j) {
    _j++; // here's the change inside the new scope
    setTimeout(function () {
      console.log("j: " + _j + " seconds");
    }, _j * 1000);
    j = _j; // here's the change being propagated back to maintain continuity
  };

  for (var j = 0; j < 5; j++) {
    _loop(j);
  }
})();


Derek Ziemba brings up an interesting point:

Internet Explorer 14.14393 doesn't seem to have these [performance] issues.

Unfortunately, Internet Explorer incorrectly implemented let syntax by essentially using the simpler var semantics, so comparing its performance is a moot point:

In Internet Explorer, let within a for loop initializer does not create a separate variable for each loop iteration as defined by ES2015. Instead, it behaves as though the loop were wrapped in a scoping block with the let immediately before the loop.


* This transpiled version on Babel's REPL demonstrates what happens when you declare a let variable in a for loop. A new declarative environment is created to hold that variable (details here), and then for each loop iteration another declarative environment is created to hold a per-iteration copy of the variable; each iteration's copy is initialized from the previous one's value (details here), but they're separate variables, as proven by the values output within each closure.

For this question. I try to find some clue form chrome V8 source code. here is the V8 loop peeling code:

https://github.com/v8/v8/blob/5.4.156/src/compiler/loop-peeling.cc

I try to understand it, I consider for loop has a middle layer in the implementation. for loop will hold the increment value in middle layer.

If loop use let to declare "i", V8 will declare a new variable i for every loop iterations, copy value of middle layer increment variable to that new declared "i", then put it to loop body scope;

If loop use var to declare "i", V8 will only put the middle layer increment value reference to the loop body scope. It will decrease the performance overhead of loop iteration.

Sorry for my pool english. There is a graph in the v8 source code, it will show you the mechanism.

本文标签: javascriptWhy is let slower than var in a for loop in nodejsStack Overflow