3 ms·

> 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

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

by eyko 10y ago

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.