stream() / parallelStream() methods

[Remi Forax]

On 02/09/2013 04:36 PM, Kevin Bourrillion wrote:
> On Sat, Feb 9, 2013 at 4:09 AM, Doug Lea <dl at cs.oswego.edu 
> <mailto: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.

It depends if the operation that you perform for each item take a long 
time or not.

>
>
>     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.


Rémi