It's kind of awesome how good TypeScript looks in all this. Testament to the compiler talent MS has on staff.
Performance of ES6 features relative to ES5
11–20 of 71 posts
Re: Performance of ES6 features relative to ES5
#12Note, when it says "1.6x faster" what is really means is "1.6 as fast" or "60% faster", or really "operates at 1.6x the speed of the baseline", not "1.6x increase in speed". 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,…
Yea in that example it might matter, but I'm seeing places where it's 10x or 100x slower. At that point, it hardly matters.
Correct, at the extremes, the numbers don't matter. But where it says "1.2x slower", it really means "84% of baseline" [1], which might be a bit misleading.
[1] https://github.com/kpdecker/six-speed/blob/master/data.json#...
Re: Performance of ES6 features relative to ES5
#13These measures are JS performance are important for VM implementors, for people writing node.js applications to be used at large scale and people doing computationally-complex work in the browser (eg creating physics engines).
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
Re: Performance of ES6 features relative to ES5
#14The 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 …)
Re: Performance of ES6 features relative to ES5
#15The 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 Go…
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.
Re: Performance of ES6 features relative to ES5
#16I would like to see Babel ES6-to-ES5 converted performance here too, because that's how most real-world ES6 code is going to be run --- there are too many non-ES6-compatible browsers out there.
That's exactly the information the "babel" rows provide? Each row is a given "ES6 implementation" and how it performs compared to the baseline "ES5 native" implementation of a feature. 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 v…
Oh, FFS. I managed to spend some time looking at the table without actually seeing what the entire point of it was.
Tea, you have failed me!
Sorry about that.
Re: Performance of ES6 features relative to ES5
#17More than just these, even innocuous features such as `let` and `const` over `var` cause a substantial performance decrease in V8 (but not SpiderMonkey).
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.
Re: Performance of ES6 features relative to ES5
#18The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations. 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…
> The thing about JIT languages is that there's no such thing as overall speed of a particular operation
Except for the ASM.js subset of operations perhaps.
Re: Performance of ES6 features relative to ES5
#19Why is "identical" in green and "faster" in a slightly darker green? Is es6 a library or is it the browser's implementation of ES6?
Re: Performance of ES6 features relative to ES5
#20The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations. 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…
> The thing about JIT languages is that there's no such thing as overall speed of a particular operation; you can only sample current speed on current implementations.
How in the world is that specific to JIT? Have you never heard of a Sufficiently Smart Compiler?