I brought this topic to commons-collections because we use some streaming
in the Bloom filter implementation where we are very sensitive to
processing time.  I received this answer over there and thought I would
bring the information here:

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?
>

Link to discussion:
https://lists.apache.org/thread/1wlz9xt49n8o8rfkp8lrzy3fmpzsyqnn

Claude


On Fri, Jun 7, 2024 at 6:54 PM Jordan West <jw...@apache.org> wrote:

> Agreed Aleksey. I wouldn’t be opposed to more nuanced use but the burden
> that adds seems impractical. A simple rule is easier.
>
> Jordan
>
> On Fri, Jun 7, 2024 at 05:59 Aleksey Yeshchenko <alek...@apple.com> wrote:
>
>> It am okay with its use off hot paths in principle, and I’ve done it
>> myself.
>>
>> But as others have mentioned, it’s not obvious to every contributor what
>> is and isn’t a hot path. Also, the codebase is a living, shifting thing: a
>> cold path today can suddenly become hot tomorrow - it’s not uncommon.
>>
>> Another benefit to this binary decision flow is that we can easily
>> enforce it with our lint tooling just for non-test part of the codebase.
>> It’s just easier to scale.
>>
>>
>> On 7 Jun 2024, at 10:27, Štefan Miklošovič <stefan.mikloso...@gmail.com>
>> wrote:
>>
>> I think it makes sense to use streams to make the life easier for a dev
>> when constructing some log messages or something like that in clearly not
>> hot paths. Nothing wrong with that ... Collectors.joining(", ") and that
>> kind of stuff. I do not think that doing this aggressively and "orthodoxly"
>> is necessary.
>>
>>
>>

Reply via email to