Will the use of ES6 syntatic sugar features speed up program performance?

JavaScript
1

For example : i have a program written in stone age ecmasrcript syntax with a lot of function calls. These calls can be re-written with arrow functions. The parameters can be changed with array/object destructuring.

If i do this (change all old function calls into arrow functions, etc), will my program performs faster?

2

in many cases they are actually slower!!!

see here:
http://incaseofstairs.com/six-speed/

3

Thx, bookmarked. Hopefully it’ll improve soon. I mean, what is the point of having good-looking syntatic sugar if it’ll just slowing down performance?

4

i think the people who develop the language are not necessarily involved in the method that language is implemented across browsers… perhaps in the future it will be.

5

Make sense. Fingers crossed.

6

Entirely dependent on engine implementation. If you run the code you already have in different engines you’ll get different results. Some ES6 things reduce the possible states a program can be in, so they should be much easier to optimise for vendors, but that just takes time. Some things have no overhead. Some things are unequivocally faster though, the most obvious being rest parameters to get the arguments of a function:

function example() {
  var args = Array.prototype.slice.call(arguments);
  console.log(args);
}

That is impossible for a JS engine to optimise away, so will always be interpreted rather than compiled (as will any code it touches, as it will poison that). This can be compiled though:

function example(...args) {
  console.log(args);
}

Some things should be much faster (generators are an obvious one that should result in fast code but often don’t). Some things get out through Babel and get their performance wiped out (generators, again).

It’s dangerous to put too much faith in benchmarks though, because they are completely dependent upon browser implementation and on what the code does. If you really want very fast code, avoid objects or write the code in C/C++/Rust (though a decade or so of throwing money at optimising JS engines means JS runs pretty fast anyway). But you’re unlikely to see much noticeable difference between pre-ES6 and ES6 code in a modern browser running code directly (and if it’s compiled from ES6 to 5, then you’re running 5 anyway, so in that case just avoid stuff like generators) :man_shrugging:

7

Modern javascript engines are so quick the difference would be negligible. On larger projects ES6 syntax makes code neater and more organised which allows developers to make more maintainable and hence faster systems.

You will find far more issues with latency in network calls. Ensuring you make API calls for data in a sensible way and optimising large assets such as images is going to have a far greater performance improvement that writing code entirely in es5.

The point of ES6 is that is makes programs far easier to read, this is a massive advantage in larger projects with multiple developers. I would certainly advise learning ES6, its great to code in and now the standard in most companies using javascript.

8

Thank you for the insight, but let me simplify my question :

Here is my browser app, it is a family tree written in d3.js where you can zoom in/out with mouse scroll/finger pinch, and have a bunch of other interactions.

There is a lot of function calls there that can be re-written with arrow function, and also there are places where i can apply array & object destructuring.

If i do this, if i replace all the old syntax with the new es6 features, will my program performs faster? I would like to make sure of this, since it is quite a lot of works.

9

As stated, it’s not going to make any noticeable difference. It’ll just generally make your code simpler, easier to read, as @collinstommy says. Rendering lots of DOM elements, then adding fancy animations to them is always going to have performance implications, nothing is going to change that.

edit: D3 is not “fast” in the way I think you mean fast - it can make very nice visualisations, but it isn’t super performant, because it works by manipulating lots of DOM elements. And if you use a force layout [for example] you’re definitely sacrificing performance for pretty animations. It’s an architectural decision: you have chosen to use D3 because it’s great for data visualisation, not because it’s super performant.

2 Likes