Java Compiler: Optimization of "cascaded" ifs and best practices?

Question

Hello,

Does the Java Compiler optimize a statement like this

if (a == true) {
 if (b == true) {
  if (c == true) {
   if(d == true) {
       //code to process stands here
   }
  }
 }
}

to

if (a == true && b==true && c==true && d == true)

So that's my first question: Do both take exactly the same "CPU Cycles" or is the first variant "slower".

My Second question is, is the first variant with the cascaded if considered bad programming style as it is so verbose?

(I like the first variant as I can better logically group my expressions and better comment them (my if statements are more complex than in the example), but maybe that's bad programming style?) and even slower, that's why I am asking...

Thanks Jens

Answer 1

Firsly DONT USE a == TRUE:

 if (a) { ... }

Secondly such code:

public class Test {
  public int f(boolean a, boolean b, boolean c, boolean d) {
    if (a && b && c && d) {
      return 1;
    } else {
      return 2;
    }
  }

  public int g(boolean a, boolean b, boolean c, boolean d) {
    if (a)
      if (b)
        if (c)
          if (d)
            return 1;
    return 2;
  }
}

is compiled into(javap -c Test):

public class Test extends java.lang.Object{
public Test();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public int f(boolean, boolean, boolean, boolean);
  Code:
   0:   iload_1
   1:   ifeq    19
   4:   iload_2
   5:   ifeq    19
   8:   iload_3
   9:   ifeq    19
   12:  iload   4
   14:  ifeq    19
   17:  iconst_1
   18:  ireturn
   19:  iconst_2
   20:  ireturn

public int g(boolean, boolean, boolean, boolean);
  Code:
   0:   iload_1
   1:   ifeq    19
   4:   iload_2
   5:   ifeq    19
   8:   iload_3
   9:   ifeq    19
   12:  iload   4
   14:  ifeq    19
   17:  iconst_1
   18:  ireturn
   19:  iconst_2
   20:  ireturn

}

As you can see the bytecode is identical.

Thirdly - it depends on problem but usually it is too verbose. If you comment to such details:

• Your comments are way too verbose. Thay should support code not duplicate it (BAD: x = x + 1; // Increase x by 1) - possibly assembler is only exception as add rax, 1 ; Increase x by 1 informs that rax is x.
• Your code is doing really 'smart' things that it probably shouldn't (however some case are justified)

Answer 2

The Java "compiler" will likely not do any optimization here (compile both, and decompile them to compare). But the JVM runtime might very well do so.

However, that said, this is a micro-optimization; code so that your code is the most understandable by the next developer to come along.

The best practice here is the most readable code.

And, of course, don't use (xxx == true), which is horrible a practice, use (xxx) instead.

Answer 3

According to document, && and || operators exhibit "short-circuiting" behavior, and only evaluated if needed, so should be same CPU cycles for both way.

The && and || operators perform Conditional-AND and Conditional-OR operations on two boolean expressions. These operators exhibit "short-circuiting" behavior, which means that the second operand is evaluated only if needed.

For more info, See

• http://java.sun.com/docs/books/tutorial/java/nutsandbolts/op2.html

Answer 4

The first variant makes it easier to place a break point on one or your conditions, and stack traces for any exceptions thrown while checking your conditions will also indicate which line was being checked.

Answer 5

It's not an optimization. The two versions are completely equivalent. Neither runs faster.