You need to test it with some realistic data for a benchmark.
In Commons Statistics we have a case where all elements of an array are
passed to a consumer. So you have either:
int[] a = ...
IntConsumer c = ...
Arrays.stream(a).forEach(c::accept)
vs
for (final int i : a) {
c.accept(i);
}
When the array is less than 10 in length then the stream is noticeably
slower. When it is longer then the difference becomes mute as the cost of a
Stream is more of a constant than a scaling factor. It also depends on the
speed of the consumer as to whether you will notice. But (single threaded)
the loop is never slower. The stream provides the advantage of intermediate
state operations on the stream contents, and parallelisation. If you are
not using these then the stream is extra overhead.
So the questions are: how large is your collection that you are streaming;
what is consuming the stream; and how critical is the runtime performance
for this process?
Alex
On Wed, 12 Jun 2024 at 07:37, Claude Warren <cla...@xenei.com> wrote:
> There is/was a discussion in Cassandra Dev recently about the overhead of
> Java Streaming vs simple loops/iteration. The consensus there is that
> streams should not be used in the hot path. Discussion then devolved into
> determining hot path or banning outright.
>
> My question is should we remove the stream calls from the non-test
> bloomfilter code on the assumption that Bloom filters are always on the hot
> path.
>
> Claude
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
