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, √ ------------- PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2422078650
