> From: "Viktor Klang" <viktor.kl...@oracle.com>
> To: "Remi Forax" <fo...@univ-mlv.fr>, "core-libs-dev"
> <core-libs-...@openjdk.java.net>
> Sent: Thursday, June 13, 2024 12:52:03 PM
> Subject: Re: [External] : Gatherer and primitive specialization

> Hi Rémi,

> Given that Collector has not been specialized since it was introduced, we 
> opted
> to not specialize Gatherer eagerly as Valhalla Value Classes may also move the
> needle a bit regarding the need for specialization in general.

As i said previously, most collectors uses collections so until collections are 
specialized, specializing the collector API is not that useful. 
A gatherer unlike a Collector can just transform values, thus specializing it 
is more useful. 

For Valhalla, we are at year 10 and value classes are not there yet, 
specialization of generics is in my opinion 10 years ahead. 
I'm not complaining, if we had rush value classes, everybody will have regret 
it, but those things take a lot of time. 

> It was also not clear how far to take such specialization—since Gatherers have
> both input types and output types, should they be specialized in two axes or
> only one?

If it's like mapMulti, it's the two axis, you have 4 x 4 possible types 
(Object,int, long, double). 
And because the integrator uses an interface for being greedy or not, it's 16 
times 2. 

> It also has implications on composition of Gatherers.

If we have something like a Gatherer.ofInt() (like with Iterator or 
Spliterator), we need 4 andThen() (or one andThen with a pattern matching with 
4 cases) so it has implications but it's not a road block. 

> Cheers,
> √

regards, 
Rémi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: Remi Forax <fo...@univ-mlv.fr>
> Sent: Thursday, 13 June 2024 10:16
> To: core-libs-dev <core-libs-...@openjdk.java.net>
> Cc: Viktor Klang <viktor.kl...@oracle.com>
> Subject: [External] : Gatherer and primitive specialization
> Hello,
> the Gatherer API do not provide primitive specialization while intermediate
> methods like map(), flatMap() or mapMulti() do.

> Unlike collectors where it is okay to not be specialized because most 
> collectors
> mutate a collection that is not specialized too,
> gatherers can process/transform values so having boxing in the middle of those
> kind of computations is a performance pothole.

> I think there is a trick that can be used, we do not need to specialize all 
> the
> functions of the Gatherer API but only the integrator.
> All other functions are called a few time when a stream is processed so they 
> may
> not need specialization, only the integrator is called a lot.

> regards,
> Rémi

Reply via email to