Jack, In your article at http://java.oreilly.com/news/javaperf_0900.html you say: <pre> To avoid repeating the method call in the loop test, we can simply replace: for(int i = 0; i < collection.size(); i++) with int max = collection.size(); for(int i = 0; i < max; i++) </pre> Amazingly, while most of the VMs gain one or two percent in speed from this change, eliminating the repeated method call actually makes the 1.2 JIT VM run 40 percent slower! See test3 under Table and Listings. (While I can't imagine what makes the change so disadvantaged, I suspect it's some inefficient artifact of the native-code generation on my processor, such as an incorrect integer alignment. This likelihood is confirmed by a further test, which combines the two optimizations used so far (see test4 under Table and Listings). I wonder if you would get any improvement if you would make max final ...
[This message has been edited by Paul Wheaton (edited October 27, 2000).]
Theoretically yes. This would tell the compiler that the variable will not change whereas without the 'final' specifier, there is no such guarantee. I believe that an optimizing compiler might be able to take advantage of this information. In practice I find that the bytecodes are identical whether or not I use a 'final' specifier there - at least with the Sun compiler.
I wonder if the difference with the JIT compiler actually going slower is because the compiler has already optimized this.
Joined: Oct 26, 2000
I doubt it. 40% is a huge difference, and none of the other VMs go that way. The difference a final could give would only be a couple of percent at best. Also the slowdown goes away with further optimizations, where those optimizations could not have made up that kind of a difference. After enough further optimizations, if you test with this particular optimization and without, you find that the optimization does give a speedup. That's pretty much the signature of a performance bug. 40% slowdown is right in the ballpark for an integer misalignment: I remember seeing the same thing happen with some Specmark tests on Pentiums where different C compilers produced this kind of difference, and those differences were tracked to integer misalignment.