對.NET的性能調優來說，我們有一個普遍被誤解的觀念：規避內存分配的重要性。人們認為，由于內存分配是快速的，因此很少會對性能產生影響。

要理解導致這種誤解的原因，我們必須回到在C++和Visual Basic 4到6中所看到的COM編程時代。對于COM，內存是使用引用計數形式的垃圾回收器進行管理的。每當將一個對象分配給一個引用變量時，就會增加一個隱藏的計數器。如果變量被重新分配或從作用域退出，計數器就會被取消。如果計數器達到0，對象就會被刪除，將內存釋放到其他地方。

[[213309]]

這種內存管理系統是“確定的”。通過仔細分析，你可以確定何時刪除一個對象。這意味著你可以自動釋放數據庫連接等資源。而對于.NET而言，你需要一個單獨的機制(例如，銷毀/啟用)以確保非內存資源能夠及時地被釋放。

引用計數垃圾收集器有三個主要的缺點。首先，它們容易受到“循環引用”的影響。如果兩個對象相互引用，即使是間接的，那么引用計數也不可能降為0，這便會導致內存泄漏的發生。我們必須小心地編寫代碼，要么避免循環引用，要么提供某種解構方法以便在當對象不再需要時中斷循環。

工作在多線程環境中時會遇到另一個主要的缺點。為了避免競態條件，某種類型的鎖機制(例如:鎖住、增量、旋鎖等)需要確保重新計數仍然是正確的。這些操作出奇的昂貴。

***，可用內存位置的列表可能會變成碎片化的，在活動對象之間會產生許多小的、不可用的空間。內存分配通常涉及到遍歷一個有空閑空間的連續鏈表，以便尋找到一個足夠大的位置來滿足需求對象。(內存碎片在.NET中也存在于“大對象堆”或“LOH”。)

相比之下，像.NET或Java那樣將內存分配到一個“標記-清掃”形式的垃圾回收器中，便是一個簡單的指針增量機制。賦值并不比分配一個整數更昂貴。只有當GC實際運行時，才會支付實際成本，而且通常通過使用分代收集器來緩解這種情況。

當.NET剛出現的時候，許多人抱怨.NET的垃圾回收器不確定性的表現將會損害性能并且難以解釋。當時微軟的反駁是，對于大多數用例來說，盡管間歇的GC會暫停，但“標記-清掃”的垃圾回收器實際上會更快。

不幸的是，隨著時間的推移，這條信息變得有些混亂。即使我們接受這樣一種理論，即“標記-清掃”的垃圾回收器速度比引用計數更快，但這并不意味著它在絕對意義上是必須的。內存分配和相關的內存壓力通常是很難檢測性能問題的原因。

而且，使用的內存越多，CPU緩存的效率就越低。雖然主RAM很大，以至于在大多數用例中幾乎不會使用到基于磁盤的虛擬內存，但是相比之下，CPU中的緩存是很小的。從RAM中填充CPU緩存所需的時間可能會占用數十甚至數百個CPU周期。

在最近的一篇文章中，Frans Bouma確定了幾種優化內存使用的技術。雖然他著重關注改善ORM性能，但這些建議在各種情況下都很有用。他的這些建議包括:

避免參數數組

參數關鍵字是有用處的，但與普通的函數調用相比要昂貴，因為它需要內存分配。API應該為常用的參數計算提供無參數重載。

還應該提供一個IEnumerable 或者IList的重載，這樣集合在調用函數之前就不需要多此一舉的被復制到一個數組中了。

如果定義之后立即添加數據，可先預定義數據結構的大小

List或其他集合類可以在被填充時多次調整大小。每次調整大小的操作都會分配另一個內部數組，并由前一個數組填充。你可以通過為集合的構造函數提供一個容量參數來避免這種開銷。

惰性的初始化成員

如果你知道一個給定對象在大多數情況下是不需要的，那么你應該使用延遲初始化來避免過早地分配內存給它。通常這是手動完成的，因為Lazy 類本身需要分配內存。

早在2011年，我們就曾報道過微軟試圖通過使用類似技術來減少任務的規模。他們的報告顯示，在創建一個任務的時候花費的時間減少了49%到55%，所需空間大小減少了52%。