
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=big5">

<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>

</head>

<body dir="ltr">

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Hi Fabian,<br>

<br>

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).</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

While it may look enticing to merely propagate expected element count as an input parameter to the supplier function,</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

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

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

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

<b>throughout</b> the pipeline is going to be important for Collector.</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div style="color: inherit;" class="elementToProof" id="Signature">

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Cheers,<br>

√</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<b><br>

</b></div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<b>Viktor Klang</b></div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Software Architect, Java Platform Group<br>

Oracle</div>

</div>

<div id="appendonsend"></div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> core-libs-dev <core-libs-dev-retn@openjdk.org> on behalf of Fabian Meumertzheim <fabian@buildbuddy.io><br>

<b>Sent:</b> Wednesday, 12 February 2025 11:09<br>

<b>To:</b> core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><br>

<b>Subject:</b> JDK-8072840: Presizing for Stream Collectors</font>

<div> </div>

</div>

<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">

<div class="PlainText">As an avid user of Guava's ImmutableCollections, I have been<br>

interested in ways to close the efficiency gap between the built-in<br>

`Stream#toList()` and third-party `Collector` implementations such as<br>

`ImmutableList#toImmutableList()`. I've found the biggest problem to<br>

be the lack of sizing information in `Collector`s, which led to me to<br>

draft a solution to JDK-8072840:<br>

<a href="https://github.com/openjdk/jdk/pull/23461">https://github.com/openjdk/jdk/pull/23461</a><br>

<br>

The benchmark shows pretty significant gains for sized streams that<br>

mostly reshape data (e.g. slice records or turn a list into a map by<br>

associating keys), which I've found to be a pretty common use case.<br>

<br>

Before I formally send out the PR for review, I would like to gather<br>

feedback on the design aspects of it (rather than the exact<br>

implementation). I will thus leave it in draft mode for now, but<br>

invite anyone to comment on it or on this thread.<br>

<br>

Fabian<br>

</div>

</span></font></div>

</body>

</html>