JDK-8072840: Presizing for Stream Collectors

[Viktor Klang]

Hi Fabian,

Thanks for your patience, it took a bit of time to swap back in my thoughts on the matter, as I was considering this JBS issue as I was working on Gatherers (JEP461, JEP473, JEP485).

While it may look enticing to merely propagate expected element count as an input parameter to the supplier function,
I think it deserves some extra thought, specifically if it may make more sense to pass some sort of StreamInfo type which can provide more metadata in the future.

Another open question is how to propagate this information through Gatherers (i.e. a bigger scope than Collector-augmentation) to enable more sophisticated optimizations—because ultimately the availability of the information throughout the pipeline is going to be important for Collector.


Cheers,
√


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Fabian Meumertzheim <fabian at buildbuddy.io>
Sent: Wednesday, 12 February 2025 11:09
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: JDK-8072840: Presizing for Stream Collectors

As an avid user of Guava's ImmutableCollections, I have been
interested in ways to close the efficiency gap between the built-in
`Stream#toList()` and third-party `Collector` implementations such as
`ImmutableList#toImmutableList()`. I've found the biggest problem to
be the lack of sizing information in `Collector`s, which led to me to
draft a solution to JDK-8072840:
https://github.com/openjdk/jdk/pull/23461

The benchmark shows pretty significant gains for sized streams that
mostly reshape data (e.g. slice records or turn a list into a map by
associating keys), which I've found to be a pretty common use case.

Before I formally send out the PR for review, I would like to gather
feedback on the design aspects of it (rather than the exact
implementation). I will thus leave it in draft mode for now, but
invite anyone to comment on it or on this thread.

Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250213/3b0f5762/attachment.htm>