[venning]

> ES6 performance sucks! Strong mode is a mode for ES6, you cannot use it without using various ES6 features. However, idiomatic ES6 code currently is substantially slower than ES5, across all browsers -- easily by 2x, often by 10x or more. Due to the sheer size of ES6, plus a number of unfortunate design choices, it will likely take years until implementations catch up with ES5 optimisations, and the hundreds of man years that went into those.

This has been my suspicion for a while. Perhaps I've missed other comments to this effect, but I don't think I've heard anyone else articulate it.

[s3th]

There's definitely a lot of room for improvement. The V8 team has been working on finishing baseline implementations for all of ES6 before spending significant time optimizing particular features. But improvements are coming quickly! In the last few weeks, for example, ES6 rest parameters got 8-10x faster and Object.assign() is now as fast as _.assign() [0].

In general, we will focus on improving the performance of the most-used features first. Arrow functions, generators, etc. are high on the list.

[0]: https://twitter.com/addyosmani/status/699976753255751681

(Disclaimer: I'm a PM on the V8 team)

[venning]

I appreciate the information. I'm curious, in reference to the original quote, how much of the existing ES5 optimization story do you think can be leveraged (at least within V8) to bring ES6/7 on par with raw ES5 and how much needs to be greenfield optimizations?

[s3th]

A big difference between ES5 and ES6/7 is that the former passes through our old, highly-tuned optimizing engine Crankshaft [0] and the latter passes through our new optimizing engine TurboFan [1]. The team's expertise optimizing Crankshaft can certainly be leveraged in TurboFan, but it's not an apples-to-apples comparison. In the future, TurboFan will handle ES5 code as well.

tl;dr we're changing engines mid-flight and that has as much to do with performance differences as the ES6 features themselves.

[0]: http://blog.chromium.org/2010/12/new-crankshaft-for-v8.html [1]: http://v8project.blogspot.com/2015/07/digging-into-turbofan-...

[SerpentJoe]

I wonder which features are slow. I'm assuming generators and by extension the for-of syntax, which is otherwise a thing of beauty. I imagine proxies are somewhere between slow and horrifyingly slow.

I have noticed that none of the features I'd hoped would save cycles (const, generators, fat arrow functions) seem to be helping at all in the browsers of today.

[fenomas]

When last I checked, V8 simply triggers a deopt when it encounters any ES6 syntax at all - so just putting an unused "let foo;" in a function will kill its performance, regardless of whether any ES6 features are used.

Of course, it may be that some ES6 features will still be slow even after they've been optimized for, but right now, as a practical matter, I think ES6 is slow simply because the engines don't yet optimize it.

[madeofpalk]

Last time I checked, fat arrow functions have a performance penalty because of all the optimisations that's made around scope in regular ES5 functions can't be used.

I believe ES6 fat arrow functions are slow for a similar reasons as why regular functions are slow when you use the magic arguments variable.

[venning]

Regarding the scope optimizations: that's an interesting point. I wonder if the different scoping of let/const also create a performance penalty versus var.

[madeofpalk]

This is true as well.

[venning]

I wouldn't be surprised if const and arrow functions actually make things slower. const, or at least a naive implementation of it, requires checking if the value is changed which var does not. Perhaps that could be equally performant in time.

Arrow functions seem like they would take (marginally) longer to parse than explicit function declarations due to having a more verbose AST that does not start with unambiguous tokens. That, and you have the implicit this binding which must come with a cost. Again, in time this might be okay.

[dangoor]

Wouldn't const be checked at compile time?

[venning]

That's still a check that var is not subject to. Hence, it's a little slower (in theory).

[phpnode]

In theory, the opposite, because a compiler knows that a constant binding never changes so the value it references can be inlined everywhere it is used without having to do runtime checks. But I think engines are not doing this yet.

[venning]

I haven't written enough ES6 to answer this for myself, but doesn't the dynamic nature of the language mean that constants can be at risk of invalid LHS operations at run-time? (At least, those positioned high enough in the scope to be subject to the necessary operations, which could be a lot.) I'm thinking of eval specifically, but perhaps there are other ways of doing this.

[david-given]

How does native ES6 performance compare with the performance of ES6 compiled into ES5?

Because right now there isn't enough cross-browser ES6 support to be able to use it reliably with compilation; given that the compilation procedure is easy and relatively pain-free (at least until you see the horrifying code that Babel produces when you ask it to transpile generators), I'm wondering how much of an issue ES6 performance is in the real world.