Remember: 我们是做产品的，不是搞学术研究的 & 用事实说话，不要臆断-技术开发NET技术-Ubuntu系统_Ubuntu服务器

近来发现，有很多同事在设计ASP.NET Application时，选择用字符串拼Html文本而不用GridView等控件，原因居然是“ASP.NET太慢”。看来有必要再次明确一个本质问题：我们是做产品的，不是搞学术研究的；同时要强调一个习惯：要用事实去证明你的猜测，而不要臆断。

一、Remember：我们是做产品的，不是搞学术研究的

直接贴一个前阵子的一封邮件，“全在邮件里面了”：

发件人:
发送时间:
收件人:
主题: 答复: 关于WebService的性能损失

这个问题里面，缺少对用户场景的描述。

我认为，我们实际应该关心的并不是这两种方式的性能究竟差别有几倍，而是他们是否会对用户、对业务产生影响。

在这个例子里面，1500次的访问，WebService多出了5000毫秒，平均每次访问多出了3ms。那么我有以下几个问题：
1、当用户执行一次操作的时候，会调用几次Web Service，从而会多出多少毫秒？
2、多出的这些时间，是不是我们必须省下来，还是在允许接受的范围内、可以忽略不计？
3、如果用户的一次操作确实需要继续节省时间，是通过改接口方式更好更有效，还是通过其他方式（比如使用缓存、禁用ViewState、局部刷新等）更好更有效？

我觉得只有把这些用户场景描述出来，才好决策。只要放在正确、合适的环境之中，任何一个方法都有可能是好的方法。

我认为一个优秀的软件开发人员必须对程序的性能保持敏感。实际在.NET中，如果传递的数据量比较大，Web Service与Odbc方式的性能差距远不止3倍，另外使用反射与直接访问的方式相比性能差别可能超过百倍，使用属性与使用字段的方式相比性能也有几倍的差距。

但同时，我们不能局限在这些“倍数”中，要更多的关注这些差距所造成的最终影响，而不能单纯的从性能差距的倍数去判断是否使用某个技术。

就以差距明显的反射来说。如果是直接访问字段，只要执行几条cpu指令就够了；但如果使用反射，则可能需要执行几百条cpu指令。他们的性能差距很明显。但是，对于目前主频动辄几个G的cpu来说，这几百条指令是我们不能接受的么？即便用户的一次操作会触发成百上千次反射、一共多执行数万条cpu指令，转换成CPU时间也只是以微秒计。

反而是网络传输、磁盘IO这些影响性能的大头，也许将这些环节的性能提高10%，就会对用户或者业务产生明显的改善了。

发件人:
发送时间:
收件人:
主题: 答复: 关于WebService的性能损失

请架构的同事一起评审一下吧

发件人:
发送时间:
收件人:
主题: 关于WebService的性能损失

写了个简单的测试，

访问同一个数据库表，访问1500次，一个直接通过Odbc访问，一个通过WebService封装转发一遍，

发现使用WebService后，花费的时间大约是直接访问的3倍左右

测试的数据如下，时间单位为ms

直接访问数据库时间：
2718.75
通过WebService访问数据库时间：
7750

直接访问数据库时间：
2656.25
通过WebService访问数据库时间：
7703.125

直接访问数据库时间：
2750
通过WebService访问数据库时间：
7656.25

鉴于这个性能损失比较大，ADS访问配置库时还是直接访问数据库吧，只是把对配置库的访问放到一个单独的DLL中，避免混到一起就是。