File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Performance and the fly likes eliminating method call makes loop slower Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "eliminating method call makes loop slower" Watch "eliminating method call makes loop slower" New topic
Author

eliminating method call makes loop slower

paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20528
    ∞

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).]


permaculture Wood Burning Stoves 2.0 - 4-DVD set
Jack Shirazi
Author
Ranch Hand

Joined: Oct 26, 2000
Posts: 96
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.
paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20528
    ∞

I wonder if the difference with the JIT compiler actually going slower is because the compiler has already optimized this.
Jack Shirazi
Author
Ranch Hand

Joined: Oct 26, 2000
Posts: 96
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: eliminating method call makes loop slower