A summary of C # about the effect of Try/catch on system performance

Ever since we started thinking about the efficiency and performance of code, there's more and more things to write about, like when should I add Try/catch? Will adding too many try/catch reduce performance? Share Some ideas about the impact of Try/catch on performance today. Let's take a look at three questions:

Question one: When a piece of code is surrounded by a try block and does not add a try when there is no exception occurs, the execution process is different?

Answer to question one:

1, try{} part and not add TRY/CATCH statement block efficiency almost the same, catch{} part seems to need more than 100 times times, so as long as you do not put try{}catch{} logic of your program, this design is reasonable.

2, from my experience, the code in the try and in the case of no try, the efficiency is the same, no impact.

Question two: If there is a difference, then how much does this difference affect the performance?

Answer to question two:

1, when the same type of exception is thrown for the first time, obviously can feel the efficiency of the reduction; Or what is seen in the article: the CLR's exception handling mechanism is much more efficient than C + +.

2, as far as I learned the compilation knowledge, I feel the try catch will affect the speed of compilation, because the translation mode to backfill the exception processing address, and during the run should not affect the speed

3, no big impact on the current machine configuration, this impact is negligible

4, the impact on efficiency is not small, can be assured to use. Because even if you don't write code to catch a possible exception, the. NET Framework will also help you capture the runtime exceptions at run time, turn to their exception handlers, and the result is a pop-up dialog to prompt you, and I think everyone has seen it during debugging.

Question three: What exactly does the code of the try do? What did he do with the code that was monitored on a per-execution basis or in a similar manner, and when an exception occurred, the procedure was actively invoked to turn to exception handling.

Answer to question three:

1, from the hardware point of view, the exception and interrupt is the same mechanism, are in meeting certain conditions, by software and hardware trigger, and through the vector to the corresponding processing program. Therefore, the exception should not be affected by performance when it is not triggered.
In addition,. NET looks for a handler in the outer layer when it produces an exception, that is, if the exception is not handled in the current function, the function that calls the current function is searched, the entire application is searched, and if not, it is given to runtime, in which case the efficiency is the lowest. And more difficult to deal with.

2, if an exception occurs, I think the earlier the efficiency of the capture is higher, but often we need to capture at a suitable level, so there is a balance problem, or the specific problem of specific analysis.

3, the individual think the try catch statement is a detection statement.

try{      need to detect statement}catch (Trace Error Class) {       error action statement}

Try-detect statement run condition:
1, when the detection statement run error, throw the error class, and then according to the information provided by the error class, execute the error action statement.
2. Inefficient use of the try Catch statement I think there are several reasons, first of all, because the program needs to detect the error, then the execution of the detection statement requires more resources, and secondly, the error action statement also consumes the corresponding resources.

Summary of my :

. NET looks for a handler in the outer layer when an exception is generated, so it can be said that the earlier the capture is more efficient. If the current application does not handle the exception, then when the exception is caught, it will be looked up one layer at a time, and if no exception handler is found, it will be given to runtime , in this case, the efficiency is the lowest, and more difficult to deal with.

For performance overhead, this information is basically negligible, because "even if you don't write code to catch a possible exception, the. NET Framework will also help you capture the runtime exceptions when running, and turn to their exception handlers ...". So as long as your catch is used to catch the unpredictable exception there should be no additional overhead.

New question: Is the exception given to runtime to deal with the efficiency is the lowest?

Experience has taught me that it seems that even if the program does not appear to add a try catch or a bit slower, personally think that the code should run faster without try catch.

Guess: at which level I would like the compiler to have exception handling should be flagged. This layer jumps to the catch block once there is a catch type exception. This also affects the size of the final compiler program.

Welcome everyone to discuss together!

C # Summary of the impact of Try/catch on system performance