“提高一下dotnet程序的效率一”中关于exception的问题

看了提高一下dotnet程序的效率一中关于exception的部分和相关的评论,我觉得有些知识点可能大家平时没有注意到或没有深入的了解：

1. Exception在没有产生exception的时候,换句话说没catch到exception的时候没有效率影响. 这是不对的,try里面的语句不会被compiler优化,compiler能编译程序不是主要用途,能优化才是它的价值所在.
2. winform和webform的exception处理没有什么不同的,exception是.net framework的,是.net的重要组成部分.
3. “如果在web上传递信息的时候采用了异常机制，那么并发量大的情况下，这个开销将是吓人的”这个结论是对的,结果是当有大量exceptions的时候,你的server将会遭遇high cpu.
4. exception的处理会暂停当前的工作被优先处理,如果throw出一个exception,让它穿透,当你在最远的地方catch它的时候,性能的损耗是最多的.
5. exception的处理也是GC头疼的问题之一, 这也是high cpu的根源
6. asp.net框架里你可以在global.asax里handle所以的异常,但是并不能说明你的website就这些异常了,有写异常已经被asp.net自己处理了.比如Response.End()方法.
7. 如果你的perfmon里# of excepts thrown / sec的值超过20,建议该review一下程序了,是否真的有必要去抛出这些异常或能否避免这样的情况发生.
8. 别人说的并不一定都是对的,就像上面的7条一样.花点时间亲手做个实验吧.

千里之堤,以蝼蚁之穴溃；百尺之室，以突隙之烟焚.
I/O,Data Access,这些看似在性能上存在bottleneck的东西其实是源于我们思维的定式：你的操作系统和文件系统难道真的发挥硬盘的I/O水平了吗？你的一定要把数据放在一个叫做数据库的东西里面吗？
了解原理和内部实现, the more the better.

Feedback

#1楼    回复  引用  查看    

2008-07-07 06:25 by Angel Lucifer      

谈下俺的看法。

添加 try...catch 块确实会增加额外的开销，这本身就是由 SEH 决定的。
但是在没有异常抛出的时候，这个额外开销并不大。怕的是 try...catch 块嵌套，尤其是无意识的嵌套。这种累积性的额外开销可能会增长到影响程序性能的地步。此外，不能被编译器优化的是 try...catch 块，而不是其内部编码。

另外就是频繁的抛出异常是性能杀手，因为一旦抛出异常，在辗转展开堆栈，查找异常位置的时候，非常耗费时间。

既然说到这了，顺便再说下关于异常与性能的话题。《.NET 设计规范》里有提及，MSDN 也有那篇文章的内容。它提出了两个模式 Tester-Doer 和 Try-Parse 。

对于库开发人员来说，根本不用在乎上述问题，有问题就抛异常。当然有时候还要考虑下 Try-Parse 模式。真正麻烦的是客户应用开发人员，也就是使用库的开发人员。

还有就是绝大部分异常在产品测试的时候都会得到妥善处理。

Over...

#2楼    回复  引用  查看    

2008-07-07 06:54 by 金色海洋（jyk）      

我是采用属性来代替抛出异常。

内部代码使用 try catch 捕捉异常，然后并不向上抛，而是写到属性（ErrorMsg）里面。

调用的地方，调用函数后，先判断一下ErrorMsg是不是 '' ，不是的话，说明出现了异常。

我的数据访问函数库就是用的这种方式处理的“抛出异常”的。

http://www.cnblogs.com/jyk/archive/2008/06/15/1222637.html