The Cost of an Exception

Recently there was a bigger discussion at Dynatrace around the cost of exceptions. When working with customers we very often find a lot of exceptions they are not aware of. After removing these exceptions, the code runs significantly faster than before. This creates the assumption that using exceptions in your code comes with a significant performance overhead. The implication would be that you better avoid using exceptions. As exceptions are an important construct for handling error situation, avoiding exceptions completely does not seem to be good solution. All in all this was reason enough to have a closer look at the costs of throwing exceptions.

The Experiment

I based my experiment on a simple piece of code that randomly throws an exception. This is not a really scientifically-profound measurement and we also don’t know what the HotSpot compiler does with the code as it runs. Nevertheless it should provide us with some basic insights.

public class ExceptionTest {

  public long maxLevel = 20;

  public static void main (String ... args){

    ExceptionTest test = new ExceptionTest();

    long start = System.currentTimeMillis();
    int count = 10000;
    for (int i= 0; i < count; i++){
      try {
        test.doTest(2, 0);
      }catch (Exception ex){
//        ex.getStackTrace();
      }
    }
    long diff = System.currentTimeMillis() - start;
    System.out.println(String.format("Average time for invocation: %1$.5f",((double) diff)/count));
  }

  public void doTest (int i, int level){
      if (level < maxLevel){
        try {
          doTest (i, ++level);
        }
        catch (Exception ex){
//        ex.getStackTrace();
          throw new RuntimeException ("UUUPS", ex);
        }
      }
      else {
        if (i > 1) {
          throw new RuntimeException("Ups".substring(0, 3));
        }
      }
  }
}

The Result

The result was very interesting. The cost of throwing and catching an exception seems to be rather low. In my sample it was about 0.002ms per Exception. This can more or less be neglected unless you really throw too many exceptions – and too many means we are talking about 100.000 or more.

While these results show that exception handling itself is not affecting code performance, it leaves open the question: what is responsible for the huge performance impact of exceptions? So obviously I was missing something – something important.

After thinking about it again, I realized that I was missing an important part of exception handling. I missed out the part on what you do when exceptions occur. In most cases you – hopefully – do not just catch the exception and that’s it. Normally you try to compensate for the problem and keep the application functioning for your end users. So the point I was missing was the compensation code that is executed for handling an exception. Depending on what this code is doing the performance penalty can become quite significant. In some cases this might mean retrying to connect to a server in other cases it might mean using a default fallback solution that is providing a far less-performing solution.

While this seemed to be a good explanation for the behavior we saw in many scenarios, I thought I am not done yet with the analysis. I had the feeling that there is something else that I was missing here.

Stack Traces

Still curious about this problem I looked into how the situation changes when I collect stack traces. This is what very often happens. You log an exception and its stack trace to try to figure out what the problem is.

I therefore modified my code to now get the stack trace of an exception as well. This changed the situation dramatically. Getting the stack trace of an exception had a 10x higher impact on the performance than just catching and throwing them. So while stack traces help to understand where and possibly also why a problem occurred, they come with a performance penalty.

The impact here is often very high as we are not talking about a single stack trace. In most cases exceptions are thrown – and caught – at multiple levels. Let us look at a simple example of a Web Service client connecting to a server. First there is an exception at the Java library level for the failed connection. Then there is a framework exception for the failed client and then there might be an application-level exception that some business logic invocation failed. This now sums up to three stack traces being collected.

In most cases you should see them in your log files or application output. Writing these potentially long stack traces again comes with some performance impact. At least you normally see and you can react to them if you look at your log files regularly – which is something you do, don’t you? 😉

In some cases I have seen even worse behavior due to some incorrect logging code. Instead of checking whether a certain log level is enabled by calling log.isxxEnabled () first, developers just call logging methods. When this happens, logging code is always executed including getting stack traces of exceptions. As the log level however is set too low they never show up anywhere you might not even be aware of them. Checking for log levels first should be a general rule as it also avoids unnecessary object creation.

Conclusion

Not using exceptions because of their potential performance impact is a bad idea. Exceptions help to provide a uniform way to cope with runtime problems and they help to write clean code. You however need to trace the number of exceptions that are thrown in your code. Although they might be caught they can still have a significant performance impact. In Dynatrace we, by default, track thrown exceptions – and in many cases people are surprised by what is going on in their code and what the performance impact is in resolving them.

While exception usage is good you should avoid capturing too many stack traces. In many cases they are not even necessary to understand the problem – especially if they cover a problem you already expect. The exception message therefore might prove as being enough information. I get enough out of a Connection refused message so I do not need the full stack trace into the internal of the java.net call stack.