Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

eliminating method call makes loop slower

 
paul wheaton
Trailboss
Pie
Posts: 21346
Firefox Browser IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).]
 
Jack Shirazi
Author
Ranch Hand
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 21346
Firefox Browser IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 96
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic