Does JAVA exception have an impact on performance

When technical support is provided to OneAPM's customers, we often see many anomalies that customers are not aware of at all. After eliminating these anomalies, the code runs at a much faster rate than before. This gives us the guess that using exceptions in the code can have significant performance overhead. Because exceptions are an important part of error handling, it is not possible to discard them, so we need to measure the impact of exception handling on performance. We can look at the impact of exception handling on performance through an experiment.

Experiment

My experiment is based on a simple code that randomly throws an exception. From a scientific point of view, this is not a completely accurate measurement, and I don't know what the HotSpot compiler will do with the running code. But in any case, this code should give us some basic information.

The results are very interesting: the cost of throwing and catching exceptions seems to be 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 the exception handling itself does not affect the code performance, it does not solve the following problem: Who is responsible for the huge impact of the exception on performance?

I obviously missed some important issues.

Rethinking a bit, I realized that I missed an important part of exception handling. I didn't think about what you did when the exception occurred. In most cases you are more likely than just catching an exception! And the problem is here: in general, you will try to supplement the problem and let the application still function at the end user. So what I missed is: “” The supplementary code that was executed to handle the exception “”. Performance loss can become quite significant depending on the supplemental code. In some cases this may mean retrying to connect to the server, and in other cases it may mean using the default rollback scheme, and the solution provided by this scheme will definitely bring very poor performance. This seems to give a good explanation for the behavior we see in many cases.

But I don't think it's all right to analyze it here, but I feel that something else is missing here.

Stack trace

I am still curious about this issue, monitoring the performance of the situation when collecting strack traces.

The situation that often happens should be like this: write down the exception and its stack trajectory and try to find out where the problem is.

I modified the code for this and additionally collected an exception strack trace. This makes the situation change dramatically. The collection of anomalous strack traces has a performance impact that is 10 times higher than simply capturing and throwing exceptions. So while strack trace helps to understand where something went wrong (and possibly helps understand why the problem occurred), 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 throw and catch exceptions at multiple levels. Let's look at a simple example: The web service client connects to the server. First, there is a connection failure exception at the Java library level. After that, there will be a client failure exception at the framework level, and then there may be a business logic call failure exception at the application level. So far, a total of three strack traces have been collected. In most cases, you can see these strack traces from log files or application output, and writing these longer strack traces will also have a performance impact.

Conclusion

First of all, it is not a good idea to abandon the anomaly because of the performance impact. Exceptions help provide a consistent way to solve runtime problems and help write clean code. But we should track the number of exceptions thrown in the code, which can cause significant performance impact. So OneAPM defaults to tracking the exceptions thrown —— in many cases people are amazed at the exceptions that occur in the code and the performance penalty when solving those exceptions. Second, although it's helpful to use exceptions, you should avoid catching too many strack traces. Exceptions should be designed for anomalous situations and should be kept in mind when using them. Of course, in case you don't want to follow good programming habits, the Java language will let you know that doing so will make your program run faster and encourage you to do that.