stream() / parallelStream() methods
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