Whether Java exceptions have an impact on performance

When it comes to technical support for ONEAPM customers, we often see exceptions that many customers do not realize. After these exceptions are eliminated, the code runs at a significantly higher rate than before. This leads us to the assumption that using exceptions in code can have significant performance overhead. Since exceptions are an important part of error handling, discarding is not possible, so we need to measure the performance impact of exception handling, and we can look at the impact of exception handling on performance in an experiment.

Experiment

My experiment is based on a simple code that throws an exception randomly. From a scientific standpoint, this is not exactly an accurate measurement, and I don't know what the hotspot compiler does with the code in motion. But anyway, this code should give us some basic information.

The result is interesting: the cost of throwing and catching exceptions seems extremely low. In my case, it's about 0.02 milliseconds per exception. Unless you really throw too many exceptions (we mean 100,000 times or more), this is basically negligible. Although these results show that exception handling itself does not affect code performance, it does not solve the following problem: Who is responsible for the significant impact of an exception on performance?

I'm obviously missing out on something important.

Having thought it over again, I realized that I had missed an important part of the exception handling. I'm not thinking about what you did when the anomaly happened. In most cases you're probably more than just catching an exception! And here's the problem: in general, you try to add to the problem and make the application work for the end user. So what I'm missing is "the supplemental code that is executed to handle the exception." Depending on the supplemental code, performance losses can become quite noticeable. In some cases this may mean a focus on the server, in other cases it may mean using the default rollback scheme, and the solution provided by this solution will certainly result in very poor performance. This seems to give a good explanation for the behavior that we see in many situations.

But I do not think that the analysis here is all right, but I feel that there is something else missing.

Stack Trace

I'm still curious about this issue, monitoring how performance changes when collecting Strack trace.

What happens often is this: write down the exception and its stack trajectory, and try to figure out where the problem is.

For this I modified the code to collect additional exception Strack trace. That makes a dramatic difference. The collection of Strack trace for an exception has a performance impact of 10 times times higher than simply capturing and throwing an exception. So while Strack Trace helps to understand where the problem occurs (and may also help to understand why the problem is occurring), there is a performance penalty. Since we are not talking about a strack trace, the impact here is often very large. In most cases, we have to throw and catch exceptions at multiple levels. Let's look at a simple example: a WEB service client connects to a server. First, there is a connection failure exception at the Java library level. Then there will be a client failure exception at the framework level, and then there may be a business logic call failure exception on the application level. So far, a total of three strack trace has to be collected. In most cases, you can see these strack trace from the log file or the application output, and writing these long Strack Trace can also have a performance impact.

Conclusion

First of all, because of the performance impact of the exception is not a good idea. Exceptions help provide a consistent way to troubleshoot run-time problems and help write clean code. But we should keep track of the number of exceptions thrown in the code, which can cause significant performance impact. So ONEAPM the default to keep track of the exceptions thrown--and in many cases people are surprised by the exceptions that occur in the code and the performance loss in resolving those exceptions. Second, despite the benefits of using exceptions, you should avoid catching too many strack trace. Exceptions should be designed for exceptional situations and should be used in keeping with this principle in mind. Of course, in case you don't want to follow good programming habits, the Java language lets you know that doing so will make your program run faster and encourage you to do that.