Does anyone have a decent explanation of why? I'm confused why () => {} would be slower than function(){}.bind(this).

Becaue that binding is tigher than...

    (function(){ 
      var __that = this; 
      return function(){
        /*switch __thatthat/this ref*/
      }; 
    }());

The code in question isn't just a binding, and it will have other differences... The code above is similar to what babel does iirc.

Now, that said there are other differences, such as ensuring that let variables are properly scoped and const doesn't allow reassign... that doesn't even begin with the maps and other new strong types that require additional locking and checks that will be less performant in many scenarios.

It's more about stable software with understandable, manageable code more than it is absolute, raw performance.

For your specific example, probably because the implementation is different.

The most notable difference is that arrow functions do not set the "arguments" variable, but there are other subtleties.

I'm not sure how it is done in V8 and co, but if the code is highly optimized, you might have to rewrite big chunks of it, even for small differences, because your optimizations do not go along with a slightly different implementation, or to avoid painful regressions.

I too would love to see prove for that, and possibly a good benchmark suite so we changes in performance between releases.

https://kpdecker.github.io/six-speed/ is what I based my comment on. It seems to have improved since I last looked and ES6 will probably suffice performance-wise.

Things like destructuring, are still 10x slower in Node 5.8 than through Babel, for example (and even 100x slower in Firefox). The spread parameter is similar. They're both used a lot in modern JS (when using Redux, for example). It's good that there are native implementations now, but both for performance and compatibility most people will/should probably keep transpiling ES6 for now.

> Things like destructuring, are still 10x slower in Node 5.8 than through Babel, for example (and even 100x slower in Firefox). The spread parameter is similar.

That's interesting. I had no idea there was such a drop in performance - orders of magnitude in some engines!

It's not as much about ES6 constructs being slower, it's just that they're newer so haven't been optimised as much yet.

This is an important point. If your usage of these techniques is not on a hot critical path, I think there's much to gain by continuing to use them as the native optimizations continue to improve.

Note that this is comparing whatever Babel does with destructuring to the native implementation, in the same engine.

This means two things:

1) Comparing these numbers across engines is pointless: if engine A runs the Babel code 5x faster than engine B but runs the native code at the same sped as enging B, this table will show engine A with a 5x bigger slowdown over Babel than engine B.

2) To make the comparison at all reasonable, this assumes the Babel implementation is correct per spec.

I can't speak to what Babel is doing here, but simply looking at the tests in https://github.com/kpdecker/six-speed/tree/master/tests/dest... it's clear that the "es5" version and "es6" version are testing different behaviors: the former indexes into the array, while the latter destructures it. Indexing is fundamentally a O(1) operation in array length, while destructuring is O(N) unless you manage to prove quite a lot statically about your operating environment, and they will produce different results in general (though again, if you can prove enough statically about your operating environment you may be able to prove that they are identical). This happens because in ES2015 array destructuring is defined in terms of array iteration, not indexing.

In practice, proving anything statically about JS is a nightmare at best and impossible in pretty much any case of interest, so the best you can do with destructuring is dynamic sanity checks on the hot path...

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1177319 for some more info, though not much.

It's been mentionned already on the thread talking about this benchmark: it's broken and does not give any interesting infos about real life performances (https://news.ycombinator.com/item?id=11203183)

This is important to fix, but I don't see this as a bigger issue. Imho, the most important is to keep the performance of existing code on par.

Right, I worded it badly. The performance of ES6 code is more of an issue for people who want to switch from transpilers to running ES6 natively (something that's hard to recommend at this point). ES5 code performing slower because of ES6 features should indeed not happen and be avoided.