parallelStream() methods (original) (raw)
Doug Lea dl at cs.oswego.edu
Sat Feb 9 07:47:28 PST 2013
- Previous message: stream() / parallelStream() methods
- Next message: stream() / parallelStream() methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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()".
-Doug
- Previous message: stream() / parallelStream() methods
- Next message: stream() / parallelStream() methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list