; that was simple is now considerably less so. That’s a cost; not convinced
> the two are in balance.
>
>
> On Mar 4, 2019, at 12:35 AM, August Nagro wrote:
>
> Hi everyone,
>
> My implementation is at
> https://github.com/AugustNagro/presize-collectors-bench and I have a
e why such huge change is
> necessary.
>
> With best regards,
> Tagir Valeev.
>
> On Mon, Mar 4, 2019 at 7:36 AM August Nagro wrote:
> >
> > Hi everyone,
> >
> > My implementation is at
> https://github.com/AugustNagro/presize-collectors-bench and I have a
stom supplier and merger preallocation sounds
> reasonable as in this case duplicating key is an exceptional case, so we
> may expect a specific number of elements.
>
> чт, 28 февр. 2019 г., 11:38 August Nagro augustna...@gmail.com:
>
>> Tagir,
>>
>> Great to see the
Tagir,
Great to see the validating benchmarks.
> I think it's the best solution given the fact that very few collectors may
benefit from the exact known size, and this benefit usually disappears when
collectors are composed (e.g. using groupingBy: downstream toList() would
not win anything if it
on on
> the actual source, a relatively bare-bones spliterator is provided.
>
> While this could probably be improved in specific cases, the return on
> effort (and risk) is likely to be low, because `Stream::spliterator` is
> already an infrequently used method, and it would on
forward to your thoughts,
- August Nagro
