parallelStream() methods (original) (raw)

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