C#中使用try catch对系统性能的影响和处理机制的学习总结!

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

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

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

问题1的回答:

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

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

问题2的回答:

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

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

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

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

问题3的回答:

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

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

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

以上全部摘抄自网络,制作了表达上的些许修改.

我的总结:

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

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

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

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

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