RFR: 8342513: Autoboxing Overhead & Inefficient Parallel Processing

[wasif kirmani]

On Thu, 17 Oct 2024 22:41:02 GMT, wasif kirmani <duke at openjdk.org> wrote:

>> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing
>
>> [xxDark](/xxDark)
> 
> Quite an allegation. Well, I initially wrote it for IntStraem and as I mentioned the performance change I found and it was working fine. But, yes I couldn't check it thoroughly which was my bad.

> @kirmaniwasif
> 
> > The issue raised was not about the primitive streams performing unnecessary boxing, but rather about efficiently handling larger streams with more complex operations (e.g., filtering large datasets).
> 
> Wouldn't, as a user, adding `parallel()` to the stream do the exact same thing (but the user would still remain in control of whether the stream is parallel or sequential)?
> 
> > I verified the filter by implementing time changes with IntStream and found out that:
> > long startTime = System.nanoTime();
> > long count = optimizedIntStream(IntStream.range(0, 1_000_000))
> > .filter(n -> n % 2 == 0)
> > .count();
> > long endTime = System.nanoTime();
> 
> The above kind of performance benchmarking is highly likely to give you the wrong impression (there are a lot of concerns you'll have to handle in order to arrive at a benchmark setup which will produce reliable results)—you'll have to create (or reuse an existing) JMH-based benchmark. Also, only testing a single stream length (which also happens to have a known length) is not going to paint a complete picture, so you're going to have to test different stream lengths ranging from 0 to millions both with streams of known lengths and unknown lengths. Also, only testing a single intermediate operation might obscure the fact that a change can have adverse effects when combined with other operations, so you're going to have to bench a bunch of combinations of operations to make sure that the change doesn't have unintended performance consequences.
> 
> What I'd recommend you doing is first verify the claims: is auto-boxing happening, and if so where. Then the next step is to check if it is possible to fix that auto-boxing locally (since the primitive streams try very hard to avoid boxing).
> 
> From experience, it is vital run the tests after each change (even before running the benchmarks).
> 
> Please see https://openjdk.org/contribute/ for further information on contributing to OpenJDK.
> 
> Cheers, √

Thank you for the response. I have closed this PR. But, will keep an eye in future

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2422085704