Answer by Peter Lawrey for Java efficiency
The times are unrealistically fast per iteration. This means the JIT has detected that your code doesn't do anything and has eliminated it. Subtle changes can confuse the JIT and it can't determine the...
View ArticleAnswer by lessthanoptimal for Java efficiency
While not directly related to this question, this is how you would correctly micro benchmark the code using Caliper. Below is a modified version of your code so that it will run with Caliper. The inner...
View ArticleAnswer by Garrett Hall for Java efficiency
When the runtime compiler can figure out testFunc evaluates to a constant, I believe it does not evaluate the loop, which explains the speedup.When the condition is removeList.size() == 0 the function...
View ArticleAnswer by thesaint for Java efficiency
Well, I am glad not having to deal with Java performance optimizations. I tried it myself with Java JDK 7 64-Bit. The results are arbitrary ;). It makes no difference which lists I am using or if I...
View ArticleAnswer by Sean Owen for Java efficiency
That is really surprising. The generated bytecode is identical except for the conditional, which is ifle vs ifne.The results are much more sensible if you turn off the JIT with -Xint. The second...
View ArticleAnswer by user949300 for Java efficiency
These benchmarks are tough since compilers are so darned smart. One guess: Since the result of testFunc() is ignored, the compiler might be completely optimizing it out. Add a counter, something like...
View ArticleJava efficiency
I'm playing with some piece of code calculating the time needed to compute some Java code to get a feeling of the efficiency or inefficiency of some of Java's functionality. Doing so I'm stuck now with...
View Article
