在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
自从开始考虑代码的运行效率和性能以后,写代码考虑的东西越来越多了,比如什么时候应该加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、从硬件角度讲,异常和中断是同样的机理,都是在满足一定的条件的时候,由软件和硬件触发,并通过向量转到相应的处理程序。因此,异常在没有被触发的时候,应该是不会对性能造成影响的。 2、如果发生了异常,我认为捕获的越早效率越高,但往往我们需要在一个合适的层面上来捕捉,所以有一个平衡问题,还是得具体问题具体分析. 3、个人觉得try catch语句是侦测语句。 try { 需要侦测语句 } catch(跟踪错误类) { 错误操作语句 } try侦测语句运行情况:
我的总结: .net在产生异常时是逐步向外层查找处理程序的,因此可以说捕获的越早效率越高.如果当前应用程序没有对异常进行处理,那么当捕获到异常时就会一层一层向外查找,如果没有查找到异常处理程序,就交给runtime,在这种情况下,效率才是最低的,而且比较难于处理。 对于性能上的开销,按照以上的信息基本可以忽略,因为"就算你不写代码去捕获可能出现的异常,.net Framework在运行时也会帮你捕获运行时出现的异常,转向其异常处理程序...".所以只要你的catch是用来捕获的不可预知的异常应该就不会有额外的开销. 新的疑问:异常交给runtime进行处理效率才是最低的? 经验告诉我似乎即使程序不出现异常时似乎加了try catch的还是要稍慢,个人认为不加try catch时代码的运行速度应该比较快. 猜测:我想编译时在哪个层次上有异常处理应该是被标记了的.该层以下一旦有catch类型异常就跳转到catch块.从而也影响了最终编译程序的大小.
欢迎大家一起探讨! |
请发表评论