try-catch slowness for static methods in Java

Question

I was checking out this discussion: How slow are Java exceptions? and while experimenting, found out that if I run static methods instead of instance methods, the normal path actually takes more time than try-catch path.

What I'm doing is: create a no-op static foo() method, create static method method1() that calls foo() 100000000 times normally, and another static method method2() which calls foo() 100000000 times in a try-catch block. What I see is, method2 actually takes less time than method1.

Any thoughts?

public class ExceptionsStatic
{
    public static void main(String... args)
    {               
        withNormal();
        withTry();      
    }

    static void foo()
    {

    }

    static void foo2() throws Exception
    {

    }

    static void withTry()
    {
        long t1 = System.currentTimeMillis();

        for(int i = 0; i < 100000000; i++)
        {
            try
            {
                foo2();
            }
            catch(Exception e)
            {

            }
        }

        long t2 = System.currentTimeMillis();

        System.out.println("try time taken " + (t2 - t1));
    }

    static void withNormal()
    {
        long t1 = System.currentTimeMillis();

        for(int i = 0; i < 100000000; i++)
        {
            foo();
        }

        long t2 = System.currentTimeMillis();

        System.out.println("normal time taken " + (t2 - t1));
    }
}

Answer 1

I have attempted to re-create your test code and then run it through javap. These are given at the end so that you don't have to scroll through a large text block.

Note that when there is no absolutely no optimisation performed by the VM, the bytecode is executed as per the javap dump below. Thus, assuming no other external factors, execution of method2() should always take longer as it includes an additional instruction (line 11: goto 15).

Of course, as Joachim mentions below, 'the bytecode says very little about performance'.

There are a lot of flags available for profiling and enabling/disabling JVM optimisations. Have a look around online. For 1.4.2, I found this link which may work with newer JREs also.

Edited to add: In supported VMs, you can enable JIT trace output by using the following VM flag -XX:-PrintCompilation.

---

javap output:

Ryan-Schippers-MacBook-Pro-2:Miscellaneous work$ javap -c -classpath ./src SlowTryCatch
Compiled from "SlowTryCatch.java"
public class SlowTryCatch extends java.lang.Object{
public SlowTryCatch();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   return

public static void foo();
  Code:
   0:   return

public static void method1();
  Code:
   0:   iconst_0
   1:   istore_0
   2:   iload_0
   3:   ldc #2; //int 100000000
   5:   if_icmpge   17
   8:   invokestatic    #3; //Method foo:()V
   11:  iinc    0, 1
   14:  goto    2
   17:  return

public static void method2();
  Code:
   0:   iconst_0
   1:   istore_0
   2:   iload_0
   3:   ldc #2; //int 100000000
   5:   if_icmpge   21
   8:   invokestatic    #3; //Method foo:()V
   11:  goto    15
   14:  astore_1
   15:  iinc    0, 1
   18:  goto    2
   21:  return
  Exception table:
   from   to  target type
     8    11    14   Class java/lang/Exception


}

Answer 2

I have modified your code a bit so the optimizer does not remove code. By running it several times in Sun/Oracle JVM the things I have found are:

• Execution time is not deterministic. This is usual in HotSpot JVMs, especially in multicore systems
• Differences between withNormal() and withTry are minimal. This is to be expected as no actual exception is ever thrown and there are no finally blocks.
• The version that is run first tends to be slower. It might be something related to the HotSpot compiler "warming up", but I am not an expert in HotSpot internals

To summarize, I would not expect any significant difference between code using exceptions or not, when running in Sun/Oracle JVM it is most likely noise from HotSpot.

UPDATE

I have run it with both -server and -client flags and apart from execution being an order of magnitude faster in my machine, the observations above apply.

Modified code below:

public class ExceptionsStatic    {

public static void main(String... args)
{
    withNormal();
    withTry();
}

static int fooVar;
static void foo()
{
    fooVar++;
}

static int foo2Var;
static void foo2() throws Exception
{
    foo2Var++;
}

static void withTry()
{
    long t1 = System.currentTimeMillis();

    foo2Var = 0;
    for(int i = 0; i < 100000000; i++)
    {
        try
        {
            foo2();
        }
        catch(Exception e)
        {

        }
    }

    long t2 = System.currentTimeMillis();

    System.out.println("try time taken " + (t2 - t1) + "; " + foo2Var);
}

static void withNormal()
{
    long t1 = System.currentTimeMillis();

    fooVar = 0;
    for(int i = 0; i < 100000000; i++)
    {
        foo();
    }

    long t2 = System.currentTimeMillis();

    System.out.println("normal time taken " + (t2 - t1) + "; " + fooVar);
}

Answer 3

Here is a micro benchmark which sucks less. Use 1 or 2 as program parameters and -XX:+PrintCompilation -verbose:class -verbose:gc as JVM parameters.

public class TryBlockBenchmark {
    private static final int MEASUREMENTS = 100;
    private static int dummy = 0;

    public static void main(String[] args) {
        boolean tryBlock = args[0].equals("1");
        System.out.println(tryBlock ? "try block" : "no try block");

        for (int i = 0; i < MEASUREMENTS; i++) {

            long start = System.currentTimeMillis();
            if (tryBlock) {
                benchmarkTryBlock();
            } else {
                benchmarkNoTryBlock();
            }
            long end = System.currentTimeMillis();

            System.out.println((end - start) + " ms");
        }

        System.out.println("(" + dummy + ")");
    }

    private static void benchmarkTryBlock() {
        for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
            try {
                staticMethod();
            } catch (Exception e) {
            }
        }
    }

    private static void benchmarkNoTryBlock() {
        for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
            staticMethod();
        }
    }

    private static void staticMethod() {
        dummy++;
    }
}

With Java 1.6.0_24 64-bit HotSpot Server VM on a C2Q6600 @ 3GHz, after the first couple of measurements, the time for both versions stabilizes at 266 ms (+/- 1 ms). The time is the same also when the staticMethod() is inlined manually, which is to be expected from HotSpot. Removing the dummy++ line reduces the time to 0 ms, when HotSpot optimizes it away.

I also tested using Java 1.6.0_24 32-bit and with it the HotSpot Server VM had the same results, but the HotSpot Client VM had both versions producing results around 8660 ms (+/- 20 ms).

So we can conclude that the Server VM has better optimizations than the Client VM and that a try-catch which does nothing is either optimized away by HotSpot or that it does not affect the performance. To find which it is, print the assembly code produced by HotSpot.

Overall, measuring things which do nothing is pretty pointless.