performance - javascript 'let' and 'var' in for-loops

Question

On my search for concrete numbers to back usage of the const keyword in Javascript, I stumbled upon a performance comparision between all three variable declaration types var, let and const. I didn't like the test setup, so I created a simplified one.

I didn't expect much difference and Firefox measured up to my expectations:

But in Chromium something weird happened:

Not only are all test results significantly lower but let inside the loop breaks down to a fraction of the speed.

I decided to run the tests in Browserstack to make sure it is not my quirky Linux setup. The same happens there with Firefox 53 and Chrome 58 on Windows 10. I even tested the somewhat older Chrome 50 and got the same behaviour.

What is going on? Is it a bug?

EDIT: Some commented that the loop is probably just optimized away as it is doing nothing. To show, that this is not the case, I changed the test.

Answer 1

When you use let the body of the for loop must create a new scope to handle the correct lifetime for the loop variable, however in many cases it is possible to optimise away the extra code and runtime. For example consider this code:

let sum = 0;
let fns = [];
for (let i=0; i < 1000; i++) {
  function foo() { sum += i; }

  fns.push(foo);

}

When you run it through babeljs you can see the equivalent ES5 code it produces includes a function call in order to preserve the correct variable lifetimes:

var sum = 0;
var fns = [];

var _loop = function _loop(i) {
  function foo() {
    sum += i;
  }

  fns.push(foo);
};

for (var i = 0; i < 1000; i++) {
  _loop(i);
}

However, babel is intelligent enough that if you don't do anything which requires extending the lifetime of the loop variable it simply uses an ordinary for loop with the body inline. So your code:

for (let i=0; i < 1000; i++) {
  true;
}

can be shown to be exactly equivalent to:

for (var i=0; i < 1000; i++) {
  true;
}

My guess would be that something very similar happens internally in Chrome, but they haven't yet optimised out the cases where they don't have to keep the loop variable alive.

It would be interesting to see how the code I used at the top of this example compares in Firefox and Chrome as I suspect they should both end up similarly slow. You should beware of timing things like empty loops as the results can be skewed by optimisation far more than is normal for actual code.