parallelStream() methods (original) (raw)

Brian Goetz brian.goetz at oracle.com
Sat Feb 9 10:48:49 PST 2013

The separation of parallel() from stream() also presents more possibilities for the user, and therefore also raises questions. Where in the expression does parallel() belong? In the parallel string-compare example, I had a choice between boxed().parallel() or parallel().boxed(). Which is "right"? Or maybe I should insert parallel() even later in the expression?

Good question. Clearly more education will be needed here.

There's two axes on which to evaluate how to use .parallel() and .sequential(); semantic and performance.

The semantics are straightforward. If a stream starts out sequential, then:

foo.filter(...).parallel().map(...)

will do the filtering sequentially and the mapping in parallel. Whereas

foo.parallel().filter(...).map(...)

will do both in parallel. I think users can understand that aspect of it; it seems pretty straightforward.

If the stream is already s/p then s()/p() are no-ops (well, a single virtual call and a field read.)

On the performance front, that's always a moving target, but currently .parallel() on a "naked" (no ops added yet, as in the second case) stream is much cheaper than .parallel() on a stream that already has ops (like in the first case.)

More information about the lambda-libs-spec-observers mailing list