一、通常的效能問題型別

讓我們一起看看那些公共的效能問題,看看他們是或者不是.我們將瞭解到為什麼我們常常在開發期間會錯過這些問題.我們也會看看當我們考慮效能時語言的選擇、延遲、頻寬、計算等因素.

二、語言的考慮

　　人們經常關注所使用的程式語言的速度。然而，這經常沒有抓住要點。這是一個非常簡單的觀點，掩蓋了技術選擇的細微差別,用任何語言編寫速度慢的軟體都很容易。由於當今計算機的處理速度非常強大，所以解釋效能相對較慢的語言通常足夠快，而開發中效能的提高是值得的.要理解所涉及的論點和權衡是很重要的，即使在讀完這本書之後您決定使用C#和.NET.

　　編寫速度最快的軟體的方法是深入瞭解底層硬體並用組合語言編寫。（甚至機器程式碼）。但開發、除錯和測試都很複雜，這需要專家形知識。我們現在很少這樣做，除了非常小的應用程式（如虛擬現實遊戲、科學資料處理，有時還有嵌入式裝置），但通常只用於軟體的一小部分.

 C＃在速度和靈活性之間提供了良好的平衡，使其適用於各種各樣的應用程式，尤其是伺服器端Web應用程式

三、效能問題的類別

1.延遲

記憶體延遲

網路延遲

磁碟IO延遲

繁瑣的互動/握手

2.頻寬

過載的負荷

未優化的資料

壓縮的平衡

3.計算問題

工作於過於大量的資料

計算非必須的結果

暴力的演算法

4.響應

可離線處理的同步操作

快取及處理作廢的資料

　　在為平臺編寫軟體時，通常會受到兩種資源的限制。即:計算處理速度和訪問遠端（到處理器）資源。處理速度如今很少是一個限制因素，這可以用於與其他資源進行交易,例如，壓縮一些資料以減少網路傳輸時間。訪問遠端資源（如主記憶體，磁碟和網路）將產生各種時間成本。瞭解處理速度不是受單個值影響，而是多個引數影響非常重要。這些引數中頻寬和延遲是最重要的,

　　延遲是操作開始之前的滯後時間，而頻寬是資料在操作開始後轉移的速率。提交一個硬碟驅動事件的頻寬是非常高的，也是具有非常高的延遲的。這會使來回傳送大量文字檔案變得非常慢，但是或許，傳送大量3D視訊是一個不錯的選擇（取決於Weissman

得分了）。

　　行動電話資料連線可能更適合文字檔案。 雖然這是一個人為的例子，但是同樣的問題通常適用於計算堆疊的每一層，其時間差的數量級相似。 問題在於差異太快無法察覺，我們需要使用工具和科學來看待它們。

　　解決效能問題的祕訣是對該技術有更深入的瞭解,並知道在較低級別會發生什麼。 您應該瞭解框架在網路級別上的說明。 掌握這些命令如何在底層硬體上執行以及它們如何受到部署到的基礎架構的影響也很重要。

四、什麼時候效能是重要的

　　效能並不總是很重要。知道什麼時候是重要的,什麼時候不重要,是非常必要的技能。一般的經驗法則是，如果使用者需要花事件來等待事情發生，那麼就應該讓效能良好。如果可以非同步執行對使用者沒有影響,就可以按照非同步地方式執行,如:佇列,或者其他非UI執行緒.

某些情況下,程式被設計為看起來緩慢,主要的原因是為了系統安全,例如一些解密演算法.

五、為什麼常常沒有發現效能問題

　　在開發中沒有注意到效能問題的主要原因之一是一些問題在開發系統上是不可感知的。在延遲增加之前可能不會出現問題。這可能是因為大量的資料被載入到系統中並且檢索特定的記錄需要更長的時間。這也可能是因為每個系統被部署到單獨的伺服器上，從而增加了網路等待時間。另外當資料量沒有上來,或者請求量沒有上來,這些問題都是難以發現的.所以提前的壓測是很有必要的.

　　當您從一開始就考慮效能時，解決問題的成本更低、速度更快。對於軟體開發中的大多數問題來說，這都是正確的。越早抓到BUG，越好。發現錯誤的最糟糕的時間是一旦部署，然後由使用者報告。與功能性BUG相比，效能問題有點不同，因為它們通常只在規模上顯示出來，除非您去尋找它們，否則在實際部署之前您不會注意到它們。您可以編寫整合測試和負載測試，以對照具體的量化目標檢查效能，我們將在本書後面討論這些目標。