Understanding system expenses for C + + exception handling

In order to handle exceptions at run time, the program logs a large amount of information. Wherever it is executed, the program must be able to identify which object will be freed if an exception is thrown here, and the program must know each entry point to exit from the try block, and for each try block, They all have to track the catch clauses associated with them and the types of exceptions that these catch clauses can catch. The record of this information is not without cost. Make sure that the program meets the exception specification without run-time comparisons (runtime comparisons), and that when the exception is thrown, there is no extra overhead to free the related object and match the correct catch words. But exception handling is a cost, even if you do not use the Try,throw or catch keyword, you also have to pay some price.

Let's start with the price you have to pay without using any exception handling features. You need space to set up data structures to track whether objects are fully constructed (constructed) (join clause 10), and you also need system time to keep these data structures constantly updated. These costs are generally not very large, but programs that are compiled with methods that do not support exceptions are generally less expensive to run faster than programs that support exceptions.

In theory, you can't choose this: the C + + compiler must support exceptions, that is, you can't have the compiler manufacturer eliminate the overhead when you don't have to do exception handling, because the program typically consists of multiple independently generated object files (object file). Only one target file does not perform exception handling and does not perform exception handling on behalf of other target files. And even if the target files that make up executables do not handle exceptions, what about the libraries they are connected to? If any part of the program uses an exception, the other part must also support the exception. Otherwise, it is not possible for the program to provide proper exception handling at run time.

But this is just a theory, in fact, most compiler manufacturers that support exceptions allow you to freely control whether or not to include content that supports exceptions in the generated code. If you know that any part of your program does not use Try,throw or catch, and you know that the library you are connecting to does not use Try,throw or catch, you can compile with a method that does not support exception handling, which reduces the size and speed of the program. Otherwise you will have to pay for an unwanted feature. As time goes on, the use of heterogeneous libraries is becoming commonplace, and this approach will gradually become impossible, but according to the current software development situation, if you have decided not to use any of the exception features, then using a method that does not support exceptions to compile the program is a reasonable way to optimize performance. This is also a good way to optimize performance for libraries that want to avoid exceptions. This ensures that exceptions are not passed from the client to the library, but doing so also prevents the client program from redefining the virtual functions declared in the library, and does not allow callback functions that are defined at the client.

The second cost of using exception handling comes from a try block, and whenever you use it, that is, whenever you want to catch an exception, you have to pay the price. Different compilers implement try blocks in different ways, so the overhead between compilers and compilers is not the same. Roughly, if you use a try block, the size of the code increases by 5%-10% and the speed of the operation slows down. This assumes that the program does not throw an exception, and I'm talking here about the overhead of using a try block in a program. To reduce overhead, you should avoid using useless try blocks.

The compiler generates as many code for exception specifications as they generate for the try block, so an exception specification typically spends as much overhead as a TYR block. What, you say you think anomaly specs are just a spec, you think they don't produce code? Well, now you should have a new understanding of that.

Now we are at the heart of the problem and look at the overhead of throwing an exception. In fact, we don't need to be too concerned about this, because anomalies are very rare, and the occurrence of such events is often described as exceptional (unusual, rare). The 80-20 rule (see Clause 16) tells us that such an event does not have much impact on the performance of the entire program. But I know you're still curious to know how much overhead it would be if you threw an exception, and the answer is that it might be bigger. Returning from a function by throwing an exception can be three orders of magnitude slower than a normal function return. This is a big expense. But only when you throw an exception does this cost, and it doesn't usually happen. But if you use an exception to represent a more general condition, such as completing the traversal of a data structure or ending a loop, you must reconsider it.

But wait a minute, you ask me how do I know these things? If supporting exceptions is a newer feature for most compilers, and if different compiler exception methods are different, how can I say that the size of the program will increase by 5%-10%, and that its speed also slows down with the same ratio, And if a lot of exceptions are thrown, will the program run at an order of magnitude? The answer is alarming: some rumors and some benchmark tests (benchmarks) (see article 23). The fact is that most people, including compiler manufacturers, have little experience with exception handling, so while we know that exceptions do incur overhead, it is difficult to predict the exact amount of overhead.

The prudent approach is to have an understanding of the costs described in this article, but not to delve into specific quantities. No matter how expensive the exception handling is, we have to stick to the principle that we pay only when we have to pay. In order to minimize your overhead, if possible, try to compile the program with methods that do not support exceptions, limit the use of try blocks and exception specifications to where you really need them, and throw an exception only if it is an exception (exceptional). If you still have problems with performance, evaluate your software overall to determine if exception support is a contributing factor. If so, consider selecting other compilers that can be more efficient in C + + exception handling.