Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Echoing everyone else, Java microbenchmarking is annoying. You should proably use Caliper or whatever anyone else posts.

Of course since I've never used any of them, here's my terrible example with stream beating for loop.

https://gist.github.com/anonymous/2395fb0728e491bc54f5

Warmup Warming up done 9262288 # for loop 6156414 # stream Done

edit: tuning WARMUP_RUNS to something lower (like 500 vs 10k) and for loop wins consistently vs warmup runs at 10k.

If I put on -XX:+PrintCompilation I see some extra compilation output but I don't really understand the output. I assume some of this contributes but there's way more output then I expected tbh

     4929  263       3       java.lang.invoke.LambdaForm$DMH/1581781576::invokeStatic_L_L (14 bytes)   made not entrant
   4929  339       4         java.util.function.Predicate::isEqual (20 bytes)


Yes your example is bad. If JIT inlines through, the code is trivially dead and can be removed. So yes, please use proper bench harness (JMH).


Ya I thought it might mark it as dead but even if I append the result to something like a List and print the list at the end (so it can't just not run the code?), Stream wins. Anyway I'm off to work for today, maybe I'll post in evening.

edit: https://gist.github.com/anonymous/ed0d8f4a5c6553fe8435

Is there some way in this example it could not actually run the code here?


Well, you're not really testing for loops since 5there are other artifacts here:

1) forEach driver method is receiving multiple types, it's not monomorphic 2) you may be hitting OSR compilations 3) for loop may hit range checks on each get() 4) for loop version warms the cache for the stream version and this benchmark is mem ref heavy

So, please try to use JMH to get more accurate picture. And, as mentioned, this isn't really testing for loop vs streams.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: