Remember: 我们是做产品的，不是搞学术研究的 & 用事实说话，不要臆断
近来发现，有很多同事在设计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中，避免混到一起就是。
上面的这个例子很明显的说明了做产品与做学术研究的差别。可以说原来的同事在做决策的时候出发点没有放在业务上，过多的关注了性能的差距，而没有关注这些差距会对业务造成的影响。
二、Remember：要用事实去证明你的猜测，而不要臆断
这两天与另外一个Team的同事合作。某个页面上要求用表格显示一组统计数据。下面是一段对话：
：我们用GridView还是直接拼Html文本？
：（很疑惑，赶紧回顾了一下需求，发现没有比如嵌套表格之类的什么特殊格式）有现成的控件为什么还要拼Html文本呢？
：GridView很慢，会影响性能。
：#_#
类似的对话我听过不止一个人说过。
老实讲，能推断出这个理论的，一般都不是那种一只脚刚踏进Asp.Net大门的新手，估计他们已经明白了Asp.Net是怎样将aspx页面及对应的代码最终变成发往客户端的Html文本的。
但可惜的是，他们缺少了一个很重要的精神：就是上面邮件中那位同事“用事实去检验推论”的习惯。上面邮件中的同事用事实去验证了自己的推断，而提出GridView会影响性能的同学估计绝大多数都没有动手去写一段代码测试一下，虽然测试的代码很简单。
当然，我们都没有那么死板，考虑到验证结论所需要额外消耗时间，我们需要用“投入产出比”去判断我们所下的推论到底要不要动手去验证一下。如果是一个影响很小的推论，不去验证也就算了，让经验决定；但如果是大的决定，比如上面邮件中的问题涉及到了系统架构，以及上面对话中如果抛弃Gridview，系统中众多的表格需求将会消耗很多额外的时间，这些问题就必须慎重，一定不能仅仅靠猜测就去下一个如此重要的结论。
事实上，从性能上来讲使用GridView并不会增加多少Cpu耗时。一般的表格使用GridView与直接拼Html几乎没有性能差别。需要注意的是，当GridView绑定的数据很多，比如几百上千行，页面可能会慢。但必须了解这是因为http协议在传输文本时导致的页面慢，而不是因为使用了WebControl而没有直接拼Html。
总之，作为一个优秀的开发人员，必须对性能保持敏感，但同时更重要的是：一定要弄清楚并关注这些性能问题对业务、对产品所可能造成的影响。
