[[428811]]

本文轉載自微信公眾號「DotNET技術圈」，作者Raygun 。轉載本文請聯系DotNET技術圈公眾號。

在Raygun[1]，我們是一群非常懂多種語言的開發人員。Raygun的各個部分使用不同的語言和框架編寫-最好的工作方式。

鑒于大量的C#和我們正在處理的數據的爆炸性增長，在不同的時間需要進行一些優化工作。大部分重大的收獲往往來自于真正地重新思考問題并從全新的角度解決問題。

今天我想分享一些C#性能技巧，這些技巧對我的最新工作有所幫助。其中一些功能在你看來也許相當微不足道，因此請不要在這里充電并使用所有功能。就這樣，提示1是…

1.每個開發人員都應使用分析器

有一些很棒的.NET分析器。我個人使用了Jet Brains[2]團隊的dotTrace分析器。我知道我們團隊中的Jason 也從Red Gate分析器中[3]獲得了很多價值。每個開發人員都應安裝并使用探查器。

我無法數出我認為應用程序的最慢部分在一個區域中的次數，而實際上卻完全在其他地方。探查器對此提供了幫助。此外，有時候，它可以幫助我發現錯誤-緩慢的部分之所以緩慢，只是因為它做錯了什么(單元測試

沒有

正確地拾取它)。

這是您要執行的所有優化工作的第一步，也是有效的第一步。

2.抽象級別越高，速度越慢(通常)

這只是我聞到的氣味。您使用的抽象級別越高，通常越慢。我在這里發現的一個常見示例是在代碼繁忙的部分(也許在循環中被稱為數百萬次)中使用LINQ。LINQ非常適合快速表達某些內容，而這些內容可能要花一堆代碼，但是您通常會將性能留在桌面上。

不要誤會我的意思-LINQ非常適合讓您開發出可運行的應用程序。但是在代碼庫中以性能為中心的部分中，您可能會付出太多。特別是因為將這么多操作鏈接在一起非常容易。

我所使用的特定示例是我使用的地方.SelectMany().Distinct().Count()。鑒于這被稱為數千萬次(由我的探查器發現的關鍵熱點)，它正在累積大量的運行時間。我采用了另一種方法，并將執行時間減少了幾個數量級。

3.不要低估發行版和調試版

我一直在努力工作，對獲得的性能感到非常滿意。然后，我意識到自己已經在Visual Studio中進行了所有測試(我經常將性能測試編寫為也可以作為單元測試運行，因此我可以更輕松地運行自己關心的部分)。我們都知道發行版本已啟用優化。

因此，我做了一個發布版本，稱為從控制臺應用程序測試的方法。

我對此有了很大的轉變。我的代碼已經瘋狂地進行了優化，因此確實是時候對.NET JIT編譯器進行一些微優化了。啟用優化后，我的性能提高了約30%!這使我想起了我不久前在網上閱讀的一個故事。

這是上世紀90年代的一個古老游戲編程故事，當時內存限制非常嚴格。在開發周期的后期，團隊最終將耗盡內存，并開始考慮必須刪除或降級哪些內容以適合可用的微小內存空間。資深開發人員根據他的經驗就曾期望這樣做，并在項目一開始就分配了1MB的內存和垃圾數據。然后，他節省了一天的時間，并刪除了他在項目開始時立即分配的1MB內存，從而解決了問題!

知道團隊總是沒有足夠的空間，因為那里有可用的內存，就可以為團隊提供他們所需要的東西，并按時發貨。

我為什么要分享這個?在性能方面類似–在調試模式下獲得足夠好的運行，并且您將在發行版本中獲得一些“免費”性能。美好時光。

4.看大局

有一些很棒的算法。您多數不需要每天甚至每月都不用。但是，值得知道它們的存在。我經常進行研究后，就會發現一種更好的解決問題的方法。在編碼之前進行研究的開發人員與在編寫代碼之前進行適當分析的開發人員的可能性差不多。我們喜歡代碼，并且總是想直接進入IDE。

此外，通常在查看性能問題時，我們過于專注于單個生產線或方法。這可能是一個錯誤–放眼全局，可以通過減少需要完成的工作來幫助您顯著提高性能。

5.內存位置很重要

假設我們有一個數組數組。實際上是一張桌子，尺寸為3000×3000。我們要計算有多少個插槽的值大于零。

問題–這兩個中哪個更快?

for (int i = 0; i < _map.Length; i++) 
{ 
    for (int n = 0; n < _map.Length; n++) 
    { 
          if (_map[i][n] > 0) 
          { 
            result++; 
          } 
    } 
} 
for (int i = 0; i < _map.Length; i++) 
{ 
    for (int n = 0; n < _map.Length; n++) 
    { 
          if (_map[n][i] > 0) 
          { 
            result++; 
          } 
    } 
} 

回答?第一個。在我的測試中，此循環使性能提高了8倍!

注意區別嗎?這是我們遍歷此數組數組的順序([i] [n]與[n] [i])。即使我們從自己管理內存中抽象出來，內存局部性在.NET中的確很重要。

就我而言，這種方法被稱為數百萬次(準確地說是數億次)，因此我可以從中獲得的任何性能都獲得了可觀的勝利。再次感謝我經常使用的分析器，以確保我專注于正確的地方!

6.減輕垃圾收集器的壓力

C#/.NET具有垃圾回收功能。垃圾收集是確定哪些對象當前已過時并刪除它們以釋放內存中空間的過程。這意味著在C#中，與C ++之類的語言不同，您不必手動維護不再有用的對象的刪除，即可聲明其在內存中的空間。相反，垃圾收集器(GC)處理所有這些，因此您不必這樣做。

問題是沒有免費的午餐

問題是沒有免費的午餐。收集過程本身會導致性能下降，因此您實際上并不希望GC一直收集。那么如何避免這種情況呢?

有許多有用的技術可以避免對GC施加太大壓力[4]。在這里，我將只關注一個技巧：避免不必要的分配。這意味著要避免這樣的事情：

List<Product> products = new List<Product>(); 
products = productRepo.All(); 

第一行創建了一個完全無用的列表實例，因為下一行返回另一個實例并將其引用分配給變量。現在想象一下上面的兩行是否在一個執行數千次的循環中?

上面的代碼可能看起來像一個愚蠢的示例，但是我已經在生產中看到了這樣的代碼，而不僅僅是一次。不要只關注示例本身，而要關注一般建議。除非確實需要，否則不要創建對象。

由于GC在.NET中的工作方式(這是一個世代的GC流程)，因此較舊的對象更有可能收集較新的對象。這意味著創建許多新的，短暫的對象可能會觸發GC運行。

7.不要使用空的析構函數

標題說明了一切-請勿在類中添加空的析構函數。Finalize每個具有析構函數的類的條目都會添加到隊列中。然后在調用析構函數時調用我們的老朋友GC來處理隊列。空的析構函數意味著這一切都是徒勞的。

請記住，就性能而言，GC執行并不便宜，正如我們已經提到的。不要不必要地導致GC工作。

8.避免不必要的裝箱和拆箱

裝箱和拆箱就像垃圾回收一樣，在性能方面很昂貴。因此，我們希望避免不必要地進行操作。但是他們在實踐中會做什么?

裝箱就像創建引用類型框并將值類型的值放入其中一樣。換句話說，它包括將值類型轉換為“對象”或該值類型實現的接口類型。取消裝箱相反，它會打開包裝盒并從其中提取值類型。為什么會有問題呢?

好吧，正如我們已經提到的，裝箱和拆箱本身就是昂貴的過程。除此之外，當您裝箱一個值時，您會在堆上創建另一個對象，這給GC帶來了額外的壓力(您已經猜到了!)。

那么，如何避免裝箱和拆箱呢?

通常，您可以通過避免.NET(版本1.0)中早于泛型的API來做到這一點，因此，它們必須依賴于使用對象類型。例如，更喜歡通用集合，例如System.Collections.Generic.List，而不是System.Collections.ArrayList。

9.當心字符串連接

在C#/。NET中，字符串是不可變的。因此，每次執行一些看起來好像在更改字符串的操作時，它們都會創建一個新的字符串。這些操作包括類似的方法Replace和Substring，同時也串聯。

提防串聯大量字符串，尤其是在循環內部

因此，這里的技巧很簡單-注意不要串聯大量字符串，尤其是在循環內部。在這種情況下，請使用System.Text.StringBuilder類，而不要使用“ +”運算符。這樣可以確保不會為連接的每個部分創建新實例。

10.隨時關注C#的發展

最后，我們以非常籠統的建議作為結尾-請密切關注C#語言的更改和發展方式。C#團隊不斷提供可以對性能產生積極影響的新功能。

我們可以提到的一個最新示例是C#7中引入的ref[5] return 和ref locals[6]。這些新功能允許開發人員按引用返回并將引用存儲在局部變量中。C#7.2引入了Span[7] 類型，從而可以對內存的連續區域進行類型安全的訪問。

諸如此類的新功能和類型不太可能被大多數C#開發人員使用，但是它們無疑會對性能至關重要的應用程序產生影響，值得進一步了解。

C#性能很重要!

這只是我發現對提高.NET代碼性能有用的幾件事的集合-但是值得花時間檢查代碼以確保其性能。您的團隊和客戶將感謝您!

References

[1] Raygun: https://raygun.com/

[2] Jet Brains: https://www.jetbrains.com/

[3] Red Gate分析器中: http://www.red-gate.com/products/dotnet-development/ants-performance-profiler/

[4] 許多有用的技術可以避免對GC施加太大壓力: https://michaelscodingspot.com/avoid-gc-pressure/

[5] ref: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/ref-returns

[6] 和ref locals: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/ref-returns

 

[7] Span: https://docs.microsoft.com/en-us/dotnet/api/system.span-1?view=netcore-3.0