Loose-ends wrapup

[Brian Goetz]

Well, try it -- write a trivial Collector and compare parallel 
collect(toList()) vs collect(toConcurrentBag()).

My guess is that concurrent bag will win, largely because toList() still 
does too much copying (and if it didn't, it would create view trees with 
higher per-element-access costs.)

On 5/11/2013 11:02 AM, Doug Lea wrote:
> Yet another self-reply...
>
> On 05/10/13 13:02, Doug Lea wrote:
>> On 05/09/13 15:14, Brian Goetz wrote:
>>
>>> What others have I missed?
>>
>> The lambda-dev post by John Rose reminded me that we were going
>> to revisit the need for ConcurrentHashBag: A (massive) simplification
>> of CHM that only conforms to Collection interface (so among
>> other things, duplicates are allowed), and is handy
>> for shoving unordered elements for concurrent aggregation.
>> I've had a version of this sitting around for a year or so...
>>
>
> The empirical question is what a (renamed) ConcurrentHashBuffer
> buys you. How common is collecting into an unordered
> non-Set, non-Map destination? (CHM and CHM.newKeySet suffice
> for the others.)  And of those, what is the likelihood that these
> collections have mostly-distinct elements? If they are mostly
> the same, then hashing into a buffer will often be worse than other
> options because of all the collisions.
>
> Which all together, still seems on the marginal side for JDK
> inclusion. Maybe I should package up ConcurrentHashBuffer as
> one of our jsr166e.extra classes.
>
> (Aside: it would still be nice if there were a convenient way
> for people to collect into something providing our scalable
> frequency histogram idioms.)
>
> -Doug
>
>
>
>
>
>