Improve the Performance of Loops

Question

Has anyone read "Improve the Performance of Loops" on http://archive.devx.com/free/tips/tipview.asp?content_id=3945 ?
If so, would you agree that what's written there is absolute b.....t?
He claims that decreasing the counter improves the performance and tries to prove it with the program:
for (int i=0,n=Integer.MAX_VALUE;i<n;i++){
a =-a;
// is slower than
long midTime =System.currentTimeMillis();
for (int i=Integer.MAX_VALUE-1 ; i>=0 ; i--){
a =-a;
}The result is pretty impressive:
Increasing Loop:4891
Decreasing Loop:3781
The only stupid thing is that:
1. if you run it more times you get
Increasing Loop:4891
Decreasing Loop:3781
Increasing Loop:3782
Decreasing Loop:3796
Increasing Loop:3891
Decreasing Loop:3891
Increasing Loop:3828
Decreasing Loop:3937
Increasing Loop:3891
Decreasing Loop:3906
Increasing Loop:3860
Decreasing Loop:3937
Increasing Loop:3891
Decreasing Loop:3906
So you can see that the performance is worse for decreasing loops after hotspot warmed up.
2. If you run it with -server, you'll even get:
Increasing Loop:16
Decreasing Loop:0
Increasing Loop:0
Decreasing Loop:0
Increasing Loop:0
Decreasing Loop:0
Increasing Loop:0
Decreasing Loop:0
Increasing Loop:0
Decreasing Loop:0
Increasing Loop:0
Decreasing Loop:0
Increasing Loop:0
Decreasing Loop:0
This shows that hotspot sever is much more clever than some programmers.
Even if you change the code to do something bit better like
    public TimeLoop() {
        int a = 2,b=2;
        long startTime = System.currentTimeMillis();
        for (int i = 0, n = Integer.MAX_VALUE; i < n; i++) {
            a ^= i;
        long midTime = System.currentTimeMillis();
        for (int i = Integer.MAX_VALUE - 1; i >= 0; i--) {
               a ^= i;
        long endTime = System.currentTimeMillis();
        System.out.println("Increasing Loop:" + (midTime - startTime));
        System.out.println("Decreasing Loop:" + (endTime - midTime));
          System.out.println("a="+a+" b="+b);      // Hotspot must perform _some_ kind of calculation to print this          
    }You'll find that it doesn't really matter whether you're xoring in increasing or decreasing order.
For -client:
Increasing Loop:296
Decreasing Loop:297
a=2 b=2
Increasing Loop:297
Decreasing Loop:281
a=2 b=2
Increasing Loop:297
Decreasing Loop:297
a=2 b=2
For -server:
Increasing Loop:141
Decreasing Loop:156
a=2 b=2
Increasing Loop:141
Decreasing Loop:141
a=2 b=2
Increasing Loop:140
Decreasing Loop:156
a=2 b=2
(Last three runs for each).
And I don't believe that accessing array.length is slower than storing the length in an int and comparing against that int!
Please let's just stop posting silly perfomance tuning tips!

Answer 1

Well, you can always look at the bytecode produced. I wrote two little classes:public class t {
  public static void main ( String[] args ) {
    int a = 0;
    for (int i=0,n=Integer.MAX_VALUE;i<n;i++){ a =-a; }
}andpublic class t1 {
  public static void main ( String[] args ) {
    int a = 0;
    for (int i=Integer.MAX_VALUE-1 ; i>=0 ; i--){ a =-a; }
}And here's the bytecode for their main() methods. (Extra/different bytecodes in "t" are marked):t: (incrementing)Method void main(java.lang.String[])
   0 iconst_0
   1 istore_1
==>2 iconst_0
   3 istore_2
   4 ldc #2 <Integer 2147483647>
   6 istore_3
   7 goto 16
  10 iload_1
  11 ineg
  12 istore_1
  13 iinc 2 1
  16 iload_2
==>17 iload_3
==>18 if_icmplt 10
  21 return
t1: (decrementing)
Method void main(java.lang.String[])
   0 iconst_0
   1 istore_1
   2 ldc #2 <Integer 2147483646>
   4 istore_2
   5 goto 14
   8 iload_1
   9 ineg
  10 istore_1
  11 iinc 2 -1
  14 iload_2
  15 ifge 8
  18 return The decrementing code does use fewer bytecodes to do its thing.
However, as someone pointed out - once Hotspot gets involved, all bets are off. And as someone else pointed out, if the body of the loop does nearly anything at all, the 2-bytecode-difference is going to get completely swamped.
In general, this is the kind of micro-optimizing that I'd ignore completely...
Grant