I was thinking about the same problem and if / how it could be improved. My gut feeling was always that the performance hit is relatively small, so it is not worth working on. But I was too lazy to verify this. 13% difference is definitely not worth added complexity, but 1.5-2.5x difference - well, maybe.
Anyway, regardless of the above, it is a very interesting topic and good stretch for our brains
Did you publish your benchmarks anywhere? By looking at very first benchmarks you posted here, you don’t consume the results in optimal case. Because of that, JVM could entirely remove all your code and in fact benchmark an empty function. Performance results seem like this is not happening, but still, I think it should be fixed.
The 13% performance improvement might not always be worth the individual developers replacing their use of Kotlin’s convenience functions with properly optimized loops, but enabling developers to get that benefit conveniently by doing more work on the compiler, letting all developers get a 13% performance improvement for little additional effort, would be phenomenal. Also, for the benchmarks, I called Blackhole.consumeResult, which consumes the result of the method so that it doesn’t get optimized away, though I later learned that just returning the result from the benchmark method is sufficient.
Yes, you used blackhole, but you didn’t return resultList, so it was unused. You might make the same mistake in other benchmarks as well, because the classic loop is the only case when we create the result collection manually and we have to return it at the end.
Ah, I see, I was mistakenly consuming a Unit instead of the list I was creating! I’ll try to revive my benchmarking setup sometime to see if anything changes.
This is a simple but difficult, and really important problem to solve. We should not have a standard library that encourages the writing of highly unoptimal code.
