Parallel data processing and performance - Java 8 in Action: Lambdas, Streams, and Functional-Style Programming - page 200

return LongStream.rangeClosed(1, n)
.reduce(0L, Long::sum);
}
This time the output is
Ranged sum done in: 17 msecs
The numeric stream is much faster than the earlier sequential version, generated with the iterate
factory method, because the numeric stream avoids all the overhead caused by all the
unnecessary autoboxing and unboxing operations performed by the nonspecialized stream. This
is evidence that choosing the right data structures is often more important than parallelizing the
algorithm that uses them. But what happens if you try to use a parallel stream in this new
version that follows?
public static long parallelRangedSum(long n) {
return LongStream.rangeClosed(1, n)
.parallel()
.reduce(0L, Long::sum);
}
Now, passing this function to your test method
System.out.println("Parallel range sum done in: " +
measureSumPerf(ParallelStreams::parallelRangedSum, 10_000_000) +
" msecs");
you obtain
Parallel range sum done in: 1 msecs
Finally, you obtain a parallel reduction that's faster than its sequential counterpart, because this
time the reduction operation can actually be executed as shown in figure 7.1 . This also
demonstrates that using the right data structure and then making it work in parallel guarantees
the best performance.
Nevertheless, keep in mind that parallelization doesn't come for free. The parallelization process
itself requires you to recursively partition the stream, assign the reduction operation of each
substream to a different thread, and then combine the results of these operations in a single
value. But moving data between multiple cores is also more expensive than you might expect, so
it's important that work to be done in parallel on another core takes longer than the time