parallel() (original) (raw)

stream() / parallel()

Brian Goetz brian.goetz at oracle.com
Tue Nov 27 15:02:16 PST 2012

The main issue is that you force all API developpers that want to implement a non parallel stream to have a good answer when user will call parallel().

That's not right.

Currently, the default implementation for parallel() is "stream()". Under the proposed change, the situation would be the same either way -- if the developer is willing to provide a good spliterator implementation, then it works well either seq or parallel, and if they are not, then they risk getting a weak parallel implementation. So it doesn't change the balance of what the developer has to do, or what the downside is if they do a weak job.

Given that not all sequential stream can be parallelized, what is the semantics of Stream.parallel().

Any stream can be parallelized; it just might not be a win to do so. Here's a stupid split on an arbitrary iterator: (first, rest). A slightly less stupid split is (first n, rest), where n starts at 1 (so there's something to fork immediately) and doubles until it hits some threshold (so as the pool fills up, task management overhead is reduced.)

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