4 ms·

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

Ambroos 10y ago
https://kpdecker.github.io/six-speed/ 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.
- eyko 10y ago
  > 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!
  - madeofpalk 10y ago
    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.
    - ljoshua 10y ago
      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.
  - bzbarsky 10y ago
    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/destructuring 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1177319 for some more info, though not much.
- stymaar 10y ago
  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 https://news.ycombinator.com/item?id=11203183)

Ambroos 10y ago

https://kpdecker.github.io/six-speed/ 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.

eyko 10y ago
> 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!
- madeofpalk 10y ago
  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.
  - ljoshua 10y ago
    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.
- bzbarsky 10y ago
  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/destructuring 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1177319 for some more info, though not much.
stymaar 10y ago
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 https://news.ycombinator.com/item?id=11203183)