Why the second operation is faster than the first?

Question

I'm trying to see the performance difference between for and reduce over numeric array and I can see that always the second function that I'm measuring (whatever is, for or reduce) is faster than the first. I'm guessing that it is something related to data caching or threadpool size using node. This is the code:

process.env.UV_THREADPOOL_SIZE = 1;

let array = [
  1,
  23,
  4,
  5,
  6,
  7,
  8,
  7,
  65,
  4,
  3,
  23,
  43,
  2,
  23,
  32,
  23,
  23,
  234,
  243,
  423,
  432,
  43,
  23,
  2,
  23,
  2,
  23,
];

let sum = 0;
console.time('reduce');
sum = array.reduce((s, p) => (s += p), 0);
console.timeEnd('reduce');

sum = 0;
console.time('for');
for (let i = 0; i < array.length; i++) {
  sum += array[i];
}
console.timeEnd('for');

And this code shows different results:

process.env.UV_THREADPOOL_SIZE = 1;

let array = [
  1,
  23,
  4,
  5,
  6,
  7,
  8,
  7,
  65,
  4,
  3,
  23,
  43,
  2,
  23,
  32,
  23,
  23,
  234,
  243,
  423,
  432,
  43,
  23,
  2,
  23,
  2,
  23,
];

let sum = 0;
console.time('for');
for (let i = 0; i < array.length; i++) {
  sum += array[i];
}
console.timeEnd('for');

sum = 0;
console.time('reduce');
sum = array.reduce((s, p) => (s += p), 0);
console.timeEnd('reduce');

I mean, if you reverse the order of execution, the measured results are different.

To do the test I'm using node v11.11.0

Any idea about it?

EDIT: I'm not looking for explanation why reduce is faster than for or something like that. I want to know why nodejs produce that results in this sequence of operations.

Regular `for` should always be faster, since it doesn't need to instantiate the callback and check whether there are elements to process. — briosheje, Apr 30 '19 at 15:19
I think he means that the second options is always faster, even if he switches them. — Wendelin, Apr 30 '19 at 15:20
@Wendelin nope, `for` is always faster: http://prntscr.com/nir8zg — briosheje, Apr 30 '19 at 15:21
Your benchmark could be flawed. Warm up both functions before executing. — Salman A, Apr 30 '19 at 15:43
And here is a jsperf: https://jsperf.com/sum-array-reduce-vs-for-loop — Salman A, Apr 30 '19 at 15:50

score 2 · Answer 1 · answered Apr 30 '19 at 15:41

I mean, if you reverse the order of execution, the measured results are different.

That means: Your test is somehow flawed or the results are so random, that you can't make a judgement based on them.

Run the test more often (a few thousand times), then take the average time (through that you average out the influence of other code pieces (you are running on a multithreaded machine), and you force the engine to choose it's most powerful optimization).

Before that, no judgement can be made wether one of them is faster. The result will most likely be: It does not matter, both are fast enough.

Worth reading: Which is faster? - Eric Lippert

score 1 · Accepted Answer · answered May 02 '19 at 12:43

After testing both there is no great time difference between them.

In the link, you can test it modifying the number of executions.

https://repl.it/@statefull/TrustworthyDefiniteArraylist

After some tests, the problem is on console.time function.

See this:

https://repl.it/@statefull/WrathfulCostlyIrc

The first time console.time is called it takes more time. It is compared with Date.now for each execution.

Some more tests reveal that until the first console.timeEnd the time measurement of the first console.timeEnd is not the real one.

See: https://repl.it/@statefull/SoggyLimegreenUser

score 0 · Answer 3 · answered Apr 30 '19 at 15:19

0

You add a function to the stack for each iteration of reduce (() => {} is a new function call). These function calls add a little extra time to the overall process.

As long as time constraints aren't very strict or the arrays very large, the increase to readability is generally worth it.

answered Apr 30 '19 at 15:19

Bradd

196
10

You have difficulty reading `for` loops? The reason you use `reduce` is for its higher level of abstraction, not necessarily for better readability. – Robert Harvey Apr 30 '19 at 15:20
1

@NirLevy: OK. Then that's what one should say, eh? – Robert Harvey Apr 30 '19 at 15:27
I don't have trouble reading for loops, however reduce/map/forEach/filter/find seem much easier to read and test. Two things can be easy and one can still be easier. – Bradd Apr 30 '19 at 15:36

score 0 · Answer 4 · answered Apr 30 '19 at 17:48

This is a common occurrence in scripted or JIT compiled languages, and has to do with the overhead of the compiler slowing down your operation, but only the first time. After that first time, your calling compiled code, rather than compiling a script, though this depends on how the execution engine is implemented. This is why testing generally demands that you do something not once, but several (thousand, ideally) times

score -2 · Answer 5 · answered Apr 30 '19 at 15:21

-2

Map/Reduce/Filter/Find are slow because they have callback functions, these add overhead

answered Apr 30 '19 at 15:21

colby brooks

37
4

Why the second operation is faster than the first?

5 Answers5