Home of The JavaSpecialists' Newsletter

129Fast Exceptions in RIFE

Posted: 2006-06-27Category: ExceptionsJava Version: AllDr. Heinz M. Kabutz
 

Abstract: One of the tricks that Java allows us to employ is to change the control flow of the application using exceptions. This is generally strongly discouraged, since it makes the code hard to decipher. In addition, exceptions are notoriously bad at performance. Here is a trick used in RIFE to make this work faster.

 

Welcome to the 129th edition of The Java(tm) Specialists' Newsletter. Thanks to all of you who sent me impossible-to-solve-except-by-brute-force SuDoKu puzzles :) With the help of my long-term friend Franz Mahrl, we improved the SuDoKu algorithm significantly.

Birthday and Anniversary Special: Since the 30th November 2017 is the 17th anniversary of our newsletter and my birthday is coming up on the 4th December, we are giving away a 30% discount on our new Data Structures for Java 9 Course (Late 2017 Edition). Whether you are a seasoned Java programmer or you just want to get ready for your next job interview, this course will help you. Besides detailed lectures, the course has over 130 questions that will help you discover what you missed.

Fast Exceptions in RIFE

One of the cool new open-source web component frameworks that has appeared is RIFE. At the ServerSide Java Symposium, I attended the last few minutes of a Birds-Of-A-Feather (BoF) with Geert Bevin, the architect behind RIFE.

Geert mentioned something that piqued my interest: As part of the continuations control in Java, they use exceptions to pass the control back to the client. Or something like that. Now we all know that when you construct an exception, it needs to build up a stack trace. This process can slow you down, so they change FastException to override fillInStackTrace() and do nothing.

public class FastException extends RuntimeException {
  public Throwable fillInStackTrace() {
    return null;
  }
}
  

I thought that was quite clever. Maybe not completely pure, in that you are returning from a method call in an unexpected way. In addition, this may cause the debugger to pause whenever the exception is generated.

This brought back memories of a system that I wrote with my friend Paul van Spronsen. We were trying to optimize every byte, and so we kept an instance of the exception around for reuse.

To try out the difference between the various approaches, we defined a Thrower interface:

public interface Thrower {
  public void causeException() throws Exception;
}
  

This is implemented in the SlowExceptionThrower, that simply constructs a normal exception and throws that:

public class SlowExceptionThrower implements Thrower {
  public void causeException() throws Exception {
    throw new Exception();
  }
}
  

The FastExceptionThrower makes an instance of the FastException, which does not have a stack trace. We would expect this to be faster than SlowExceptionThrower:

public class FastExceptionThrower implements Thrower {
  public void causeException() {
    throw new FastException();
  }
}
  

The last one is a SuperFastExceptionThrower that holds an instance of the exception and then simply throws that each time:

public class SuperFastExceptionThrower implements Thrower {
  private static FastException exception = new FastException();
  public void causeException() {
    throw exception;
  }
}
  

Since I am currently presenting the Java Performance Tuning course, I would like to introduce you to a tool that you can use to run microbenchmarks. JAMon is described on the Java Performance Tuning website.

import com.jamonapi.*;

public class FastExceptionTest {
  public static final int COUNT = 1000 * 1000;
  public static void main(String[] args) {
    for (int i = 0; i < 10; i++) {
      test(new SlowExceptionThrower());
      test(new FastExceptionThrower());
      test(new SuperFastExceptionThrower());
    }
  }

  private static void test(Thrower t) {
    Monitor mon = MonitorFactory.start(t.getClass().getName());
    for (int i = 0; i < COUNT; i++) {
      try {
        t.causeException();
      } catch (Exception ex) {}
    }
    mon.stop();
    System.out.println(mon);
  }
}
  

On my machine, I saw the following results:

    SlowExceptionThrower:      Avg=3,949 ms
    FastExceptionThrower:      Avg=332 ms
    SuperFastExceptionThrower: Avg=253 ms
  

JAMon makes measuring microbenchmarks a bit more convenient. We saw that caching exceptions for rethrowing later does have performance advantages.

Kind regards

Heinz

 

Related Articles

Browse the Newsletter Archive

About the Author

demo

Java Champion, author of the Javaspecialists Newsletter, conference speaking regular... About Heinz

Java Training

We deliver relevant courses, by top Java developers to produce more resourceful and efficient programmers within their organisations.

Java Consulting

Nobody ever wants to call a Java performance consultant, but with first-hand experience repairing and improving commercial Java applications - JavaSpecialists are a good place to start...

Threading Emergency?

If your system is down, we will review it for 15 minutes and give you our findings for just 1 € without any obligation.