Performance of ES6 features relative to ES5
kpdecker.github.io
kpdecker.github.io
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 …)
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.
1. whether the optimizing compiler gets used
2. random stuff that's impossible to know about unless you grab your code's internal representation and decompile it [1]
3. the raw performance of individual statements
The effects of (1) dominate (2), and the effects of (2) dominate (3). So when I see performance micro-benchmarks that purport to measure (3) without apparently paying any attention to (1) or (2), my first inclination is to assume the results are essentially random noise.
[1] E.g. whether statements get wrapped in type checks, whether an integer variable gets handled internally as a SMI (small int) or whether it keeps getting converted to a boxed Number and back. The cost of such things can easily exceed the cost of the statement you're trying to benchmark.
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.
Since then there's been work on Turbofan support for `try-catch`, but I can't tell if it's been shipped and enabled, so I could be wrong.
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.
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
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.
http://babeljs.io/repl/#?experimental=false&evaluate=true&lo...
New features pursue correctness, then as their place in the JITs mature interesting new approaches will change their speed characteristics later. Things like contrasting the speed of various ways of iterating an array are all semantically equivalent, and as the JIT learns the various semantics they should all theoretically approach similar speeds, even if the newer ones are slower now.
Except for the ASM.js subset of operations perhaps.
C compilers nowadays praised for speed used to generate worse code than junior Assembly developers on home micros.
How in the world is that specific to JIT? Have you never heard of a Sufficiently Smart Compiler?
While the release of a new AOT compiler version might not affect the performance characteristics of your application without an active choice to recompile, the release of updates to any OS components your application interacts with, may, in much the same way that a new web browser or JVM version would. The only way you get immunity from that is to bundle the whole software stack running on the bare metal as your "app", rather than relying on lower-level software that may change independently.
Wouldn't that apply to any interpreted language?
Remember when WebKit started JITing regular expressions? That changed the benchmark situation so much that some people called it cheating and not a single line of user code changed. That's not impossible in other environments – I'm sure there's been a case where a shared library update made a big difference – but it's far less common in my experience.
I do a lot of one-off demos, that I mostly write in ES6 these days. I don't have a demonstration of pure `let` vs `var`, but if you change Babel to JavaScript in this one (and click run), you'll see a fairly substantial performance decrease in Chrome for this demo (Firefox stays the same though): https://jsfiddle.net/oa1sckzu/ . I have others, and the results are largely the same for them, but I'll spare you.
It's worth noting that for most of us, most of the time, this kind of JS performance is less important than user-perceptible optimizations, like batching DOM reads and writes and decreasing asset size
So the first row of each section is the babel-compiled (to ES5) ES6, the second is traceur-compiled, third is typescript-compiled and last is native ES6 runtime. If you look at the test files, most of them only have an es5 and an es6 versions.
Tea, you have failed me!
Sorry about that.
I assume there's plenty of scope for ES6 to improve and (hopefully?) surpass ES5 in performance in many, if not all, areas?
What would be causing the large slowdowns in ES6 here? Is this a case of having features that make JS nicer to code in, but giving up some performance? Or is this more down to immature compilers not yet optimising ES6 as substantially?
Green is probably chosen because the same performance is nice to have with this (subjectively) better syntax. The darker shade is probably chosen because more performance is nice, as it pushes you to the newer (subjectively better) syntax.
For example, when looking at the data for Chrome 48's "arrow" tests [1], the baseline number is 57,858,016 and the traceur number is 91,556,806, which is 158.2% of the baseline, but is reported as "1.6x faster".
I know this seems like semantics, but "1.0x faster" sounds a lot like "twice as fast". (In this case, "1.0x faster" is reported as "identical" [2]).
[1] https://github.com/kpdecker/six-speed/blob/master/data.json#...
[2] https://github.com/kpdecker/six-speed/blob/master/tasks%2Fre...
That there is disagreement among the commentariat both ways is indicative of ambiguity. (Though, I am assuming no trolling here.)
While not exactly analogous, try replacing it with a percentage and re-evaluate: What does "60% faster" mean and what does "160% faster" mean?
To say that something that's no faster is identical to something that's "1x faster" is a terrible confusion of thought.
It's reasonable to expect that, for example, "1x faster" would mean "for a baseline of 1 operation per second, it's faster by 1 operation per second, i.e. a total of 2 operations per second."
EDIT: Oh god, that's even before I saw the "1.2x slower" entries…
Isn't this always the case with such comparisons? One is meant to multiple initialValue by e.g. 1.6 (hence the "x", for multiple), not calculate initialValue + 1.6*initialValue.
English, you subtle trickster!
There is a very distinct difference between "faster than" and "as fast as" which should be very clear now.
It's completely ambiguous with potentially significant costs for misunderstanding, but people refuse to make themselves clear, just because.
What I meant to say in my parent comment is not the use of "faster" vs "as fast" in English, but that usually in those benchmarks "Nx" means N times the speed of the baseline.
Kevin Decker, who did the site in TFA, is a native english speaker, and yet he writes "1.5x faster" to mean baseline1.5 (and not baseline + 1.5baseline).
So clearly it's not so "unambiguous" whether you can use faster in this way or not. And in fact, I've never seen any of those benchmarks where "Nx" doesn't mean the final value is N*baseline.
Very unintuitive.
"faster than" != "as fast as"
A is 50% faster than B == A is 150% as fast as B
[1] https://github.com/kpdecker/six-speed/blob/master/data.json#...
We detached this subthread from https://news.ycombinator.com/item?id=11204967 and marked it off-topic.
Also you're wrong. "__ faster" implies addition in many/most cases. Since you know what 1.6x is by itself, I'll let you use your math knowledge to calculate x + 1.6x.