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