Item M15: Understanding the system overhead of exception handling
In order to handle exceptions at run time, the program records a large amount of information:
- Regardless of where it is executed, the program must be able to identify which object will be released if an exception is thrown at this point;
- The program must know each entry point in order to exit from the try block;
- For each try block, they must keep track of their associated catch clauses and the types of exceptions that these catch clauses can catch.
The record of this information is not without cost.
while ensuring that the program meets the exception specification does not require runtime comparisons (runtime comparisons), and when exceptions are thrown, there is no additional overhead to release the associated object and match the correct catch phrase. But exception handling comes at a cost, and even if you don't use the Try,throw or catch keyword, you have to pay a price.
Let's start with the price you have to pay for not using any exception handling features.
You need space to build data structures to keep track of whether objects are fully constructed (constructed) (see article M10), and you also need CPU time to keep these data structures constantly updated.
These costs are generally not very large, but programs that do not support exception-based methods generally run faster than programs that support exceptions and have less space.
In theory, you cannot choose between these costs:
exceptions are part of C + + and the C + + compiler must support exceptions. That is
, you cannot allow the compiler manufacturer to eliminate this overhead when you do not use exception handling, because the program is typically composed of multiple, independently generated target files (object file), and only one destination file does not handle exceptions and does not handle exceptions on behalf of other target files. And even if the target files that make up the executable are not handled abnormally, are there any libraries that they are connected to? If any part of the program uses an exception, the other part must also support the exception. Otherwise, the program will not be able to provide proper exception handling at run time.
but this is only a theory, in fact, most of the compiler manufacturers that support exceptions allow you to freely control whether the generated code contains content that supports exceptions.
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 unnecessary trait. Over time, the use of the heterogeneous library began to become commonplace, the above method will gradually not be used, but according to the current software development, if you have decided not to use any of the exception features, then the method of non-exception-based compiler is a reasonable method of performance optimization. It is also a good way to optimize performance for libraries that want to avoid exceptions, which ensures that exceptions are not passed into the library from the client program, but doing so also prevents the client program from redefining the virtual functions declared in the library and does not allow the client-defined callback functions.
the second cost of using exception handling comes from a try block, whenever you use it, that is, when you want to be able to catch an exception, you have to pay the price. Different compilers implement try blocks differently, so the overhead between the compiler and the compiler is different.
roughly estimates that if you use a try block, the size of the code will increase by 5%-10% and the running speed will also slow down proportionally. This is also assuming that the program does not throw an exception, and I'm talking about the cost of using a try block in the program. To reduce overhead, you should avoid using useless try blocks.
The
code generated by the compiler for exception specifications is as much as the code they generate for a try block, so an exception specification typically spends as much overhead as a try block. What the? You say you think the exception specification is just a specification, you don't think they produce code? Well, now you should have a new understanding of it.
Now we come to the heart of the problem and look at the overhead of throwing exceptions. In fact, we don't have to be too concerned about this problem, because exceptions are rare, and the occurrence of such events is often described as exceptional (unusual, rare). The 80-20 rule (see clause M16) tells us that such events do not have much impact on the performance of the entire program. But I know you're still curious to know
if throwing an exception is going to cost a lot, the answer is that it might be larger. 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 it only happens when you throw an exception, and it doesn't usually happen. But if you use an exception to represent a more general situation, such as completing a traversal of the data structure or ending a loop, you must reconsider.
But wait a minute, you ask me how do I know these things? If the support exception for most compilers is a relatively new feature, if the different compiler exception methods are different, then how can I say that the size of the program will increase by 5%-10%, its speed is also slow down, and if a large number of exceptions are thrown, the program will run at an order of magnitude slower? The answer is alarming: some rumors and some benchmark tests (benchmarks) (see article M23). The fact is that most people, including compiler manufacturers, have little experience with exception handling, so while we know that exceptions do bring overhead, it's hard to predict the exact amount of overhead.
It is prudent to have an understanding of the costs described in these terms, but not to delve into the exact quantity (i.e. qualitative non-quantitative translator note).
no matter how expensive the exception handling is, we have to stick to the principle that only must be paid. To minimize your overhead, whenever possible, compile the program with a method that does not support exceptions, limit the use of try blocks and exception specifications to where you really need them, and throw exceptions only if the exception is true (exceptional). If you still have problems with performance, evaluate your software in general to determine if exception support is a contributing factor. If so, consider choosing other compilers that have a higher efficiency in C + + exception handling.
Summary: Using exceptions to the system overhead is very large, as far as possible with the exception!
More effective C + +----(15) Learn about the system overhead of exception handling
