4 ms·

The results given by this benchmark are bothering me because they do not fit with what I've seen in production. For example, the `for-of-array` is transpiled by

by stymaar 11y ago

The results given by this benchmark are bothering me because they do not fit with what I've seen in production. For example, the `for-of-array` is transpiled by babel to something that has 2 nested try/catch blocks, and unfortunately, V8 has a nasty deoptimisation when dealing with these, even if no exception is ever thrown. This deopt led to a several orders of magnitude slowdown compare to a simple `for` loop in Google Chrome, forcing use to abandon the `for of` construction. I suspect that the benchmark shown on this page does not expose this kind of behavior because it doesn't iterate enough for the JIT to kick in. If it's the case, it means that these values reflects only the behavior of the cold, interpreted code, and not the hot one. (which is quite sad for a performance benchmark, because the performance matter only for the former …)

berdario 11y ago
I'm not a frontend developer but... is it still truly necessary to transpile stuff like for-of ? It's supported by every desktop browser on the market, modulo some bugs (like inability to iterate over HTMLCollection and co. on Chrome)... as long as you only need to use it for arrays, things might work quite fine
- rictic 11y ago
  According to caniuse, 12% of web users in the US are on IE 11, which doesn't support for-of.
- pluma 11y ago
  Two words: Internet Explorer. Unless you're a startup and don't have to give a damn about what browsers your users use, IE marketshare is just too big to ignore. And depending on your audience, IE can mean anything from IE11 all the way back to IE8. Theoretically IE is irrelevant now that Microsoft has started publicly killing it off, but you'd be surprised at the number of corporate users that are still on Windows XP (or maybe Vista/7) running IE 8 and 9. Of course evergreen browsers are less of a problem but amazingly a lot of the same users who are stuck with IE also manage to have extremely outdated versions of Firefox.
spankalee 11y ago
Chrome doesn't have an interpreter, it has baseline and optimizing compiler. Also, I think try/catch preventing optimization was fixed. Still your point could stand, or additionally there could be many optimizations that interfere with such simple micro benchmarks, turning all or parts of them into no-ops. If this is happening in ES5 and not ES6, the results could be drastic. I suspect this is what's happening with some of the larger differences in native ES6.
- rgrove 11y ago
  > Also, I think try/catch preventing optimization was fixed. Do you have a source for this? Try/catch deopts still bubble up in my Chrome profiling, so it seems like they're still a problem.
  - goldbrick 11y ago
    Yes, my understanding is the problem is essentially undefined behavior as exceptions can be caught at any point in the call stack which makes it basically impossible to optimize.
    - kgr 11y ago
      Java optimizes try/catches.
    - bzbarsky 11y ago
      It's not impossible at all. try/catch in the non-throwing case is fast in both Firefox (SpiderMonkey) and IE (Chakra); I'm not sure what the state of things is in Safari (JavaScriptCore). In the throwing case you obviously have to do some work, but as long as that case is rare it's not a problem. Contrast with the V8 situation (which they are fixing), where simply having a try/catch in your function at all will deoptimize the function, even if an exception is never actually thrown. Oh, and one optimization strategy for try catch is even pretty simple to describe in general terms: you need a cheap way to check whether an exception is thrown, and then after every operation that can throw (e.g. a call into the vm to a function that is allowed to throw) you check whether it did. If not, you just move along. If it did, you jump to an out of line path that does cleanup and callstack unwinding. The devil, as usual, is in the details.
eltaco 11y ago
You can use loose mode which doesn't use try/catch blocks http://babeljs.io/repl/#?experimental=false&evaluate=true&loose=true&spec=false&code=let%20iterable%20%3D%20%5B1%2C%202%2C%203%5D%3B%0A%0Afor%20(let%20value%20of%20iterable)%20%7B%0A%20%20console.log(value)%3B%0A%7D http://babeljs.io/repl/#?experimental=false&evaluate=true&lo...

by stymaar 11y ago

berdario 11y ago

I'm not a frontend developer but... is it still truly necessary to transpile stuff like for-of ? It's supported by every desktop browser on the market, modulo some bugs (like inability to iterate over HTMLCollection and co. on Chrome)... as long as you only need to use it for arrays, things might work quite fine

rictic 11y ago
According to caniuse, 12% of web users in the US are on IE 11, which doesn't support for-of.
pluma 11y ago
Two words: Internet Explorer. Unless you're a startup and don't have to give a damn about what browsers your users use, IE marketshare is just too big to ignore. And depending on your audience, IE can mean anything from IE11 all the way back to IE8. Theoretically IE is irrelevant now that Microsoft has started publicly killing it off, but you'd be surprised at the number of corporate users that are still on Windows XP (or maybe Vista/7) running IE 8 and 9. Of course evergreen browsers are less of a problem but amazingly a lot of the same users who are stuck with IE also manage to have extremely outdated versions of Firefox.

spankalee 11y ago

Chrome doesn't have an interpreter, it has baseline and optimizing compiler. Also, I think try/catch preventing optimization was fixed. Still your point could stand, or additionally there could be many optimizations that interfere with such simple micro benchmarks, turning all or parts of them into no-ops. If this is happening in ES5 and not ES6, the results could be drastic. I suspect this is what's happening with some of the larger differences in native ES6.

rgrove 11y ago
> Also, I think try/catch preventing optimization was fixed. Do you have a source for this? Try/catch deopts still bubble up in my Chrome profiling, so it seems like they're still a problem.
- goldbrick 11y ago
  Yes, my understanding is the problem is essentially undefined behavior as exceptions can be caught at any point in the call stack which makes it basically impossible to optimize.
  - kgr 11y ago
    Java optimizes try/catches.
  - bzbarsky 11y ago
    It's not impossible at all. try/catch in the non-throwing case is fast in both Firefox (SpiderMonkey) and IE (Chakra); I'm not sure what the state of things is in Safari (JavaScriptCore). In the throwing case you obviously have to do some work, but as long as that case is rare it's not a problem. Contrast with the V8 situation (which they are fixing), where simply having a try/catch in your function at all will deoptimize the function, even if an exception is never actually thrown. Oh, and one optimization strategy for try catch is even pretty simple to describe in general terms: you need a cheap way to check whether an exception is thrown, and then after every operation that can throw (e.g. a call into the vm to a function that is allowed to throw) you check whether it did. If not, you just move along. If it did, you jump to an out of line path that does cleanup and callstack unwinding. The devil, as usual, is in the details.

eltaco 11y ago

You can use loose mode which doesn't use try/catch blocks http://babeljs.io/repl/#?experimental=false&evaluate=true&loose=true&spec=false&code=let%20iterable%20%3D%20%5B1%2C%202%2C%203%5D%3B%0A%0Afor%20(let%20value%20of%20iterable)%20%7B%0A%20%20console.log(value)%3B%0A%7D http://babeljs.io/repl/#?experimental=false&evaluate=true&lo...