13

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:

jsPerf results on Firefox 52

But in Chromium something weird happened:

jsPerf results on Chrome 57

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.

koehr
  • 769
  • 1
  • 8
  • 20
  • Are you sure Firefox isn't just optimizing the code? None of those code blocks actually *do* anything so could be the reason they are similar in speed. – CodingIntrigue May 08 '17 at 12:57
  • _"I created a simplified one."_ You essentially removed the whole test. You created a loop that does nothing and therefore gets optimized away. "let inside" doesn't even have side effects, that's why it's the "fastest" one. Chrome's engine doesn't seem to optimize this particular case. – a better oliver May 08 '17 at 13:07
  • @CodingIntrigue: I thought about this but running an empty loop would result in significantly higher numbers (around 18 Million on my machine). – koehr May 08 '17 at 13:22
  • possible duplicate of [Why is let slower than var in a for loop in nodejs?](http://stackoverflow.com/q/37792934/1048572) – Bergi May 17 '17 at 23:26
  • I think this is very engine specific. In Edge 15.15063.0 / Windows 10 0.0.0, there seems to be no statistically significant difference between the tests, with net speeds comparable to Chrome. – Burt_Harris May 17 '17 at 23:39

2 Answers2

3

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.

Duncan
  • 92,073
  • 11
  • 122
  • 156
  • 2
    *"My guess would be"* - reliable source. – kind user May 08 '17 at 12:48
  • There is an edit-button in jsPerf. You can add this version in a new revision any time. I'm rather interested how it can be that Chrome is the only browser that didn't optimize this. – koehr May 08 '17 at 13:00
  • 1
    @Kinduser thanks but I find my guesses are usually pretty reliable. At least as reliable as anything on the internet. What I've done is given a proposed answer to the question. Anyone else is free to cite references that either support or disprove my answer and if they do I update my answer or delete it accordingly. – Duncan May 08 '17 at 13:03
  • 1
    Don't feel offended, but... if this answer is *just your guess* and it's not backed up with any docs, books or researches, it makes your answer **primarily opinion-based** and unfortunately off-topic. – kind user May 08 '17 at 13:09
0

It's because the let keyword is somewhat new to the specification and is only applicable to the local scope. In Chrome it doesn't seem to be optimized yet, but that should only be a matter of time.

BullshitPingu
  • 79
  • 2
  • 6
  • Interestingly this doesn't happen in any of the other browsers, neither in Safari, nor in Edge. EDIT: But – as expected – in Opera, which uses the same engine as Chrome. – koehr May 08 '17 at 12:44