1

I’m talking about the case when you don’t need to return anything.

For example:

let pos = {'x': 1, 'y': 1};
['x', 'y'].forEach((val) => pos[val] = 2);

I’m curious if this implicit return affects the performance of forEach?

If we add curly braces (so the function stops returning the result of the expression), does it affect performance?

Arseny
  • 5,159
  • 4
  • 21
  • 24
  • 4
    Benchmark it…!? – deceze Jun 10 '19 at 08:14
  • 1
    Every JavaScript function has an implicit `undefined` return. So, even if you don't return anything, you are actually returning something which value is being ignored. Shortly: No, there's not any performance improvement. Modern javascript engines are smart enough to perform optimisation routines alone, and `forEach` is very optimised since it's native code – Christian Vincenzo Traina Jun 10 '19 at 08:15
  • 1
    @CristianTraìna - Not quite, at a spec level. But externally, that's what appears to happen. – T.J. Crowder Jun 10 '19 at 08:18
  • You could also add the `void` keyword for the same effect… – Bergi Jun 10 '19 at 08:33
  • I'd recommend writing `for (const val of ['x', 'y']) pos[val] = 2;` anyway. – Bergi Jun 10 '19 at 08:35
  • @Bergi - No, that still *returns* something (`undefined`). Returning vs. falling off are *slightly* different (at spec level, I don't know how much that translates to engine implementation, if at all). – T.J. Crowder Jun 10 '19 at 08:37
  • @T.J.Crowder Not to the caller of the function, they're indistinguishable. For the evaluation of the body, of course. – Bergi Jun 10 '19 at 08:39
  • @Bergi - Right, that's what I meant. – T.J. Crowder Jun 10 '19 at 08:40

2 Answers2

5

It's not going to make a difference you could detect, not even on a very, very large array. But if you're curious, you could always profile it on the JavaScript engines you care about and using your real code (since synthetic code gives synthetic results).

In specification terms, evaluating function code that completes with a return (including an arrow's implicit return) vs. just "falling off" the end of the code results in two different kinds of completion, and then the process of calling that function differentiates between the return and the non-return and supplies undefined in the non-return case. forEach's code doesn't use the result, of course, but theoretically there could be different code paths within the JavaScript engine to get there, so theoretically they could have slightly different performance.

In practice, though, I think you can safely assume JavaScript engines optimize this quite well and the difference isn't apparent.

In general, don't optimize in advance. Respond to a performance problem in a given bit of code when you have a performance problem in a given bit of code. (That said, I totally understand being interested in this sort of thing in the abstract...)

Just for fun I did a jsPerf, don't see any sigificant difference in that synthetic test on Chrome (V8) or Firefox (SpiderMonkey):

enter image description here

But again, synthetic tests give synthetic results.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
2

As with most performance questions, the right answer is to measure it.

As can be see on jsPerf, the differences are immeasurably miniscule and will most definitely be outweighed by other things, such as the overhead from forEach etc.

In reality, of course, any difference of this scale is unnoticeable.

Sample performance measurement result

Etheryte
  • 24,589
  • 11
  • 71
  • 116