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。
總之，作為一個優秀的開發人員，必須對性能保持敏感，但同時更重要的是：一定要弄清楚并關注這些性能問題對業務、對產品所可能造成的影響。
留言列表
