parallelStream() methods (original) (raw)

Kevin Bourrillion kevinb at google.com
Sat Feb 9 08:07:56 PST 2013

Belated disclaimer: one should always read my comments on performance as "please educate me because I don't get it", not "you're all wrong". :-)

On Sat, Feb 9, 2013 at 7:47 AM, Doug Lea <dl at cs.oswego.edu> wrote:

On 02/09/13 10:36, Kevin Bourrillion wrote:

I still wouldn't immediately blanch at the 64 allocations. Do users really want to use parallelism to get savings /that/ small? I thought we would care more

about the cases in which the parallelism is a huge win, not so marginal. If you take the "what's one more cycle" point of view consistently, then it would never be worth trying to parallelize anything. So minimizing seq overhead while keeping nice APIs is the only success criterion.

I will stop short of trying to convince us it's "important", but I would

definitely agree that if the cost is only some implementation ugliness, that shouldn't be enough to justify the method existing.Here's

Here's another breach in my promise not to have an opinion about anything in the Steam API: I think "parallelStream()" is much nicer than "stream().parallel()".

But the choice isn't precisely between those two; it's between having one or both. I assume that the stream().parallel() option has to exist regardless, and so users will encounter it in code, and they will have to start discussions with each other about "why did you do s().p() instead of .pS(), or vice versa, and what's the difference anyway?" Then, every time someone adds a stream() method to their type they then face the question of whether they're supposed to add parallelStream() too, etc.

I don't think absolute normalization is an API design goal in itself, but having two very similar ways to do the same thing is a definite smell.

-- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com

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