You might already know this, but there is one potential caveat with APIs like that when it comes to performance or at least measuring their performance. The hot

You might already know this, but there is one potential caveat with APIs like that when it comes to performance or at least measuring their performance. The hot loop (the code that actually iterates over your data points) does not live in your code base. But performance often depends on what the JIT compiler makes out of that loop. If the API is used at several locations in your program, the compiler might not be able to generate code that is optimal for your call-site and inputs. Instead, it will generate generalized code that works for all inputs but might be slower. However, when writing benchmarks, there is often no other code around to force the JIT compiler to generate such generalized code. The following code demonstrates this. If the parameter warmup is set, I invoke the forEach methods with different inputs first (they do the same but are different methods in the Java byte code). The purpose is to force the compiler to generate generalized code: @Param({"true", "false"}) public boolean warmup; @Setup public void setup() { if (!warmup) { Interval.oneTo(20).forEach( (IntProcedure) i -> Interval.oneTo(1_000_000).forEach( (IntProcedure) j -> Integer.toString(j))); Interval.oneTo(20).forEach( (IntProcedure) i -> Interval.oneTo(1_000_000).forEach( (IntProcedure) j -> Integer.toString(j))); Interval.oneTo(20).forEach( (IntProcedure) i -> Interval.oneTo(1_000_000).forEach( (IntProcedure) j -> Integer.toString(j))); } } @Benchmark public void coollectionsBlackhole(Blackhole blackhole) { Interval.oneTo(20).forEach( (IntProcedure) i -> Interval.oneTo(1_000_000).forEach( (IntProcedure)j -> blackhole.consume(Integer.toString(j)))); } @Benchmark public void collectionsDeadCode() { Interval.oneTo(20).forEach( (IntProcedure) i -> Interval.oneTo(1_000_000).forEach( (IntProcedure)j -> Integer.toString(j))); } And the for loop implementations for reference: @Benchmark public void loopBlackhole(Blackhole blackHole) { for (int j = 0; j < 20; j++) { for (int i = 0; i < 1_000_000; i++) { blackHole.consume(Integer.toString(i)); } } } @Benchmark public void loopDeadCode() { for (int j = 0; j < 20; j++) { for (int i = 0; i < 1_000_000; i++) { Integer.toString(i); } } } @Benchmark public void loopBlackholeOnly(Blackhole hole) { for (int j = 0; j < 20; j++) { for (int i = 0; i < 1_000_000; i++) { hole.consume(0xCAFEBABE); } } } On my desktop machine, this gives me the following results (Java 11/Hotspot/C2): Benchmark (warmup) Mode Cnt Score Error Units collectionsDeadCode true avgt 99 162.482 ± 1.615 ms/op collectionsDeadCode false avgt 99 218.816 ± 4.217 ms/op coollectionsBlackhole true avgt 99 235.122 ± 1.362 ms/op coollectionsBlackhole false avgt 99 270.192 ± 1.627 ms/op loopBlackhole true avgt 99 207.214 ± 1.162 ms/op loopBlackhole false avgt 99 206.711 ± 0.932 ms/op loopBlackholeOnly true avgt 99 74.774 ± 0.180 ms/op loopBlackholeOnly false avgt 99 74.359 ± 0.180 ms/op loopDeadCode true avgt 99 143.394 ± 0.900 ms/op loopDeadCode false avgt 99 142.654 ± 0.795 ms/op All results are for single threaded code. Now, the difference is not huge, but significant. Overall it looks like the invocation of toString(int) is not removed and accounts for most of the runtime. Just to be clear: I am not saying one should stay way from the stream APIs. As soon as the work per item is more than just a few arithmetic operations, there is a good chance the difference in runtime is negligible. But when doing numerical work (aggregations etc.), a simple loop might be the better option. Finally, these differences are of course compiler-dependent. For example, C2 might behave differently than Graal and who knows what the future brings.