自从开始考虑代码的运行效率和性能以后，写代码考虑的东西越来越多了，比如什么时候应该加try/catch？加太多的try/catch会不会降低性能？今天就来分享一下对try/catch对性能影响的一些看法。下面先来看三个问题：

问题一:当一段代码被try块包围后与不加try时在没有异常发生的情况下,执行过程是否有区别?

问题一的回答:

　　1、 try{ }部分和不加try/catch语句块的效率几乎一样, catch{}部分似乎需要100倍以上的时间 ,所以只要不把try{}catch{}作为你的程序的逻辑,这种设计就是合理的.

     2、从我的经验看来，在 try 中的代码和在没有 try 的情况下的效率是一样的，没有影响。

问题二: 如果有区别,那么这样的区别对性能的影响有多大呢?

问题二的回答:

　　1、当同一类型的异常被第一次抛出的时候，明显可以感到效率的降低；但其后再抛出就没什么感觉了。还是什么文章中看到过这样的说法：CLR的异常处理机制相比C++要高效很多。

　　2、就我学到的编译知识，感觉TRY CATCH会小小影响编译的速度，因为翻译模式内要回填异常的处理地址，而在运行期间应该不会影响速度

　　3、没什么大的影响，对现在的机器配置来说，这点影响微不足道

　　4、对效率的影响不大，可以放心使用。因为就算你不写代码去捕获可能出现的异常，.net Framework在运行时也会帮你捕获运行时出现的异常，转向其异常处理程序，结果就是弹出对话框来提示你，我想大家在调试的时候都见识过吧。  

问题三: try的代码究竟做了些什么?他对代码做的是每次执行时监视还是以类似中断的的方式,当出现异常时主动调用什么过程转向异常处理.?

问题三的回答:

　　1、从硬件角度讲，异常和中断是同样的机理，都是在满足一定的条件的时候，由软件和硬件触发，并通过向量转到相应的处理程序。因此，异常在没有被触发的时候，应该是不会对性能造成影响的。 
另外，.net在产生异常时是逐步向外层查找处理程序的，就是说，如果当前函数中没有对异常进行处理，才查找调用当前函数的那一个函数，一直找遍整个应用程序，如果还没有，就交给runtime,在这种情况下，效率才是最低的，而且比较难于处理。

　　2、如果发生了异常,我认为捕获的越早效率越高,但往往我们需要在一个合适的层面上来捕捉,所以有一个平衡问题,还是得具体问题具体分析.  

　　3、个人觉得try catch语句是侦测语句。 

try{      需要侦测语句 }catch(跟踪错误类){       错误操作语句 }

try侦测语句运行情况:
     1、 当侦测语句运行出错时,抛出错误类,然后根据错误类提供的信息,执行错误操作语句.   
     2、使用try catch语句效率低下我觉得有几个原因,首先由于程序需要进行错误侦测,那么执行侦测语句时需要更多的资源,其次,错误操作语句也要消耗相应的资源.  

我的总结:

      .net在产生异常时是逐步向外层查找处理程序的,因此可以说捕获的越早效率越高.如果当前应用程序没有对异常进行处理，那么当捕获到异常时就会一层一层向外查找，如果没有查找到异常处理程序，就交给runtime,在这种情况下，效率才是最低的，而且比较难于处理。

      对于性能上的开销,按照以上的信息基本可以忽略,因为"就算你不写代码去捕获可能出现的异常，.net Framework在运行时也会帮你捕获运行时出现的异常，转向其异常处理程序...".所以只要你的catch是用来捕获的不可预知的异常应该就不会有额外的开销.

新的疑问:异常交给runtime进行处理效率才是最低的?

经验告诉我似乎即使程序不出现异常时似乎加了try catch的还是要稍慢,个人认为不加try catch时代码的运行速度应该比较快.

猜测:我想编译时在哪个层次上有异常处理应该是被标记了的.该层以下一旦有catch类型异常就跳转到catch块.从而也影响了最终编译程序的大小.

欢迎大家一起探讨!

C# 关于Try/Catch对系统性能影响的总结