Live data from Hacker News

Performance of ES6 features relative to ES5

kpdecker.github.io

1–10 of 71 posts

Re: Performance of ES6 features relative to ES5

#2
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.

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.

Re: Performance of ES6 features relative to ES5

#4

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. 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…

[deleted]

Re: Performance of ES6 features relative to ES5

#5

I 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 versions.

Re: Performance of ES6 features relative to ES5

#9
Note, 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, 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...

Re: Performance of ES6 features relative to ES5

#10
post #9

Note, 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.
Post reply on HN