On Thu, 17 Oct 2024 22:41:02 GMT, wasif kirmani <d...@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
