stream() / parallelStream() methods
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
>> 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,
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-libs-spec-experts