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.