Тест производительности Java 8 Stream

intList.stream().max(Math::max);

The results are 6.55 ms for the for loop and 8.33 ms for the stream. My measurements are 0.700 ms and 3.272 ms. While this changes their relative performance considerably, it creates the same order:

I ascribe the marked difference between iterations over arrays and lists to boxing; or rather to the resulting indirection. The primitive array is packed with the values we need but the list is backed by an array of Integers, i.e. references to the desired values which we must first resolve.

The considerable difference between Langer’s and my series of relative changes (+14’861% +22% +27% vs +487% + 17% + 467%) underlines her statement, that “the performance model of streams is not a trivial one”.

Bringing this part to a close, her article makes the following observation:

 We just compare two integers, which after JIT compilation is barely more than one assembly instruction. For this reason, our benchmarks illustrate the cost of element access – which need not necessarily be a typical situation. The performance figures change substantially if the functionality applied to each element in the sequence is cpu intensive. You will find that there is no measurable difference any more between for-loop and sequential stream if the functionality is heavily cpu bound.

So let’s have a lock at something else than just integer comparison.

Comparing Operations

I compared the following operations:

max

Finding the maximum value.

sum

Computing the sum of all values; aggregated in an 
int ignoring overflows.

arithmetic

To model a less simple numeric operation I combined the values with a a handful of bit shifts and multiplications.

string

To model a complex operation that creates new objects I converted the elements to strings and xor’ed them character by character.

These were the results (for 500’000 ordered elements; in milliseconds):

This underlines how cheap comparison really is, even addition takes a whooping 50% longer. We can also see how more complex operations bring looping and streaming closer together. The difference drops from almost 400% to 25%. Similarly, the difference between arrays and lists is reduced considerably. Apparently the arithmetic and string operations are CPU bound so that resolving the references had no negative impact.

(Don’t ask me why for the arithmetic operation streaming the array’s elements is faster than looping over them. I have been banging my head against that wall for a while.)

So let’s fix the operation and have a look at the iteration mechanism.

Comparing Iteration Mechanisms

There are at least two important variables in accessing the performance of an iteration mechanism: its overhead and whether it causes boxing, which will hurt performance for memory bound operations. I decided to try and bypass boxing by executing a CPU bound operation. As we have seen above, the arithmetic operation fulfills this on my machine.

Iteration was implemented with straight forward for and for-each loops. For streams I made some additional experiments:

@Benchmark
public int array_stream() {
// implicitly unboxed
return Arrays
.stream(intArray)
.reduce(0, this::arithmeticOperation);
}

@Benchmark
public int array_stream_boxed() {
// explicitly boxed
return Arrays
.stream(intArray)
.boxed()
.reduce(0, this::arithmeticOperation);
}

@Benchmark
public int list_stream_unbox() {
// naively unboxed
return intList
.stream()
.mapToInt(Integer::intValue)
.reduce(0, this::arithmeticOperation);
}

@Benchmark
public int list_stream() {
// implicitly boxed
return intList
.stream()
.reduce(0, this::arithmeticOperation);
}