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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With