stream() / parallelStream() methods

[Kevin Bourrillion]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130209/c8b5dc65/attachment-0001.html