Question

I have this loop

for (it= someCollection.iterator; it.hasNext(); )
{
    //some code here
}

I changed it to:

for (it= someCollection.iterator;; )
{
    if (!it.hasNext())
        break;
    //some code here
}

The second code ran a little bit faster in unit tests in junit on eclipse.
Is the second loop faster? I’m asking because the times given by Junit are not too exact, but they give an approximate value

Answer 1

When looking into this sort of problems, it’s useful to think about the generated bytecode in terms of block control flow graph, where a block is a sequence of bytecode instructions that can only be entered from its first instruction and only left after its last instruction (leaving out exits to simplify the problem).

Using this example code:

    for (Iterator it = c.iterator(); it.hasNext(); ) {
        System.out.println(it.next());
    }
    System.out.println("Out");

You would get the following block control flow graph. I’ve put back the equivalent bytecode into source for readability, but all the instructions generated by System.out.println(it.next()); belong to one block, since you can’t jump in the middle or get out of it.

If you check a compiler book, you’ll find that it.hasNext() dominates System.out.println(it.next()) because you need to go through it.hasNext() to go to System.out.println(it.next()). The edge from System.out.println(it.next()) to it.hasNext() is called a back-edge because it links a node to one of its dominators. This is what formally defines what the loop is. The first statement in the for-loop (Iterator it = c.iterator()) doesn’t actually belong to the loop. There is no difference with a while loop preceded by this statement, except for the scope of the declared variable, but this doesn’t matter once compiled.
The first block (it.hasNext()) is the loop header.

A second example like this would produce the same graph:

    for (Iterator it = c.iterator();; ) {
        if (!it.hasNext()) {
           break;
        }
        System.out.println(it.next());
    }
    System.out.println("Out");

The main difference is that there may be some useless goto statements depending on the compiler strategy.

If you look at the generated bytecode using javap -c for these two examples, you get this (this was compiled with javac, you may get something slightly different if you compile with the Eclipse compiler, for example):

public void loop1();
  Code:
   0:   new #2; //class java/util/ArrayList
   3:   dup
   4:   invokespecial   #3; //Method java/util/ArrayList."<init>":()V
   7:   astore_1
   8:   aload_1
   9:   invokevirtual   #4; //Method java/util/ArrayList.iterator:()Ljava/util/Iterator;
   12:  astore_2
   13:  aload_2
   14:  invokeinterface #5,  1; //InterfaceMethod java/util/Iterator.hasNext:()Z
   19:  ifeq    37
   22:  getstatic   #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   25:  aload_2
   26:  invokeinterface #7,  1; //InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
   31:  invokevirtual   #8; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   34:  goto    13
   37:  getstatic   #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   40:  ldc #9; //String Out
   42:  invokevirtual   #10; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   45:  return

public void loop2();
  Code:
   0:   new #2; //class java/util/ArrayList
   3:   dup
   4:   invokespecial   #3; //Method java/util/ArrayList."<init>":()V
   7:   astore_1
   8:   aload_1
   9:   invokevirtual   #4; //Method java/util/ArrayList.iterator:()Ljava/util/Iterator;
   12:  astore_2
   13:  aload_2
   14:  invokeinterface #5,  1; //InterfaceMethod java/util/Iterator.hasNext:()Z
   19:  ifne    25
   22:  goto    40
   25:  getstatic   #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   28:  aload_2
   29:  invokeinterface #7,  1; //InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
   34:  invokevirtual   #8; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   37:  goto    13
   40:  getstatic   #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   43:  ldc #9; //String Out
   45:  invokevirtual   #10; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   48:  return

The only difference is that the first one uses ifeq 37 to go straight to the end or proceed with the next block (22), whereas the other one uses ifne to go to the block after goto (25, equivalent to 22 in the other) and uses a goto to go to the end otherwise. This is effectively equivalent and a modern JIT compiler should optimise this little difference without trouble. Apart from this, your two loops are exactly the same.

I’m not sure how you’ve made your measurements, but you should also be aware that it’s not because System.nanoTime() give you a result in nanoseconds that it has a resolution of that order, far from that. High-resolution timers are quite hard to implement and will depend on the hardware and OS. See JavaDoc:

This method provides nanosecond precision, but not necessarily
nanosecond resolution (that is, how frequently the value changes) – no
guarantees are made except that the resolution is at least as good as
that of currentTimeMillis().

It’s likely that, if you don’t get a high enough difference, you won’t get something significant compared to the resolution.