stream() / parallelStream() methods

Kevin Bourrillion kevinb at google.com
Sat Feb 9 07:36:41 PST 2013


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

On 02/08/13 18:35, Kevin Bourrillion wrote:
>
>> Doug, I am extraordinarily unmoved by this concern. :-)  Does a
>> break-even point
>> moving a few elements in either direction really matter?
>>
>
> People dealing with parallel library support need some attitude
> adjustment about such things. On a soon-to-be-typical machine,
> every cycle you waste setting up parallelism costs you say 64 cycles.
> You would probably have had a different reaction if it required 64
> object creations to start a parallel computation.
>

Well, that would also have 64x the effect on young gen GC.

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.


That said, I'm always completely supportive of forcing implementors
> to work harder for the sake of better APIs, so long as the
> APIs do not rule out efficient implementation. So if killing
> parallelStream is really important, we'll find some way to
> turn stream().parallel() into a bit-flip or somesuch.
>

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.

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


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