C # summary of the impact of try/catch on system performance

Since considering the code running efficiency and performance, there are more and more considerations for writing code. For example, when should I add try/catch? Will the performance be reduced by adding too many try/catch statements? Today, I will share my views on the impact of try/catch on performance. Let's take a look at three questions:

Question 1: Is the execution process different when a piece of code is surrounded by a try block and no try is added without exceptions?

Answer to Question 1:

1. The try {} part and the catch {} part have almost the same efficiency as those without the try/Catch Block. It seems that the catch {} part takes more than 100 times, so as long as you do not use try {} catch {} as the logic of your program, this design is reasonable.

2. In my experience, the code in the try is the same as that in the case of no try, with no impact.

 

Question 2: if there is a difference, how much will the difference affect the performance?

Answer to Question 2:

1. When an exception of the same type is thrown for the first time, the efficiency is obviously reduced. However, if it is thrown again, there is no sense. In other articles, we have seen that the CLR Exception Handling Mechanism is much more efficient than C ++.

2. As far as I learned the compilation knowledge, I feel that try catch will slightly affect the compilation speed, because the handling address of exceptions must be refilled in the translation mode, and the speed should not be affected during the running process.

3. There is no major impact on the current machine configuration.

4. It has little impact on efficiency and can be safely used. Because even if you do not write code to capture Possible exceptions ,. net Framework will also help you capture exceptions during the runtime and turn to its exception handling program. The result is a dialog box that prompts you, I think you have seen it during debugging.

 

Question 3: What is the try code? He monitors the code during each execution or in a similar way of interruption. When an exception occurs, he actively calls the process to handle the exception .?

Answer to Question 3:

1. From the hardware point of view, exceptions and interruptions are the same mechanism. They are triggered by software and hardware when certain conditions are met, and forwarded to the corresponding processing program through vectors. Therefore, exceptions should not affect performance when they are not triggered.
In addition ,. when an exception occurs, net gradually searches for the handler for the outer layer. That is to say, if the current function does not process the exception, it searches for the function that calls the current function, keep searching for the entire application. If it does not exist, it will be handed over to runtime. In this case, the efficiency is the lowest and it is difficult to handle.

2. If an exception occurs, I think the sooner the capture is, the higher the efficiency is. However, we often need to capture the exception at an appropriate level, so there is a balance problem, you need to analyze the problem.

3. I personally think the try catch statement is a detection statement.

Try {need to detect statement} catch (tracking error class) {error operation statement}

Try to detect statement running status:
1. When an error occurs during the execution of a detection statement, an error class is thrown and the error operation statement is executed based on the information provided by the error class.
2. I think there are several reasons for inefficient use of try catch statements. First, because the program needs to perform error detection, more resources are required for executing the detection statement. Second, the error operation statement also consumes the corresponding resources.

 

My summary:

. Net is gradually looking for the processing program to the outer layer when an exception occurs. Therefore, it can be said that the earlier the capture, the higher the efficiency. if the current application does not process exceptions, an external query is performed layer by layer when exceptions are caught. If no exception handler is found, the exception handler is handed over to runtime. In this case, efficiency is the lowest, and it is difficult to handle.

Performance overhead can be ignored Based on the above information, because "even if you do not write code to capture Possible exceptions ,. when netframework is running, it will help you capture exceptions during running and turn to its exception handling program... ". therefore, as long as your catch is used to capture unpredictable exceptions, there should be no additional overhead.

New question: is the lowest processing efficiency for exceptions to be handed over to runtime?

Experience tells me that even if the program does not encounter exceptions, it seems that try catch is still a little slow. I personally think that it should be faster to run without try catch.

Guess: at which level I want to compile, the exception handling should be marked. once a catch type exception occurs below this layer, the system jumps to the Catch Block. this also affects the size of the final compiled program.

 

 

Welcome to join us!