C＃提升性能的幾點提示和技巧

C＃性能提示和技巧

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

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

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

1.每個開發(fā)人員都應使用分析器

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

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

沒有

正確地拾取它）。

這是您要執(zhí)行的所有優(yōu)化工作的第一步，也是有效的第一步。

2.抽象級別越高，速度越慢（通常）

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

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

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

3.不要低估發(fā)行版和調(diào)試版

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

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

我對此有了很大的轉變。我的代碼已經(jīng)瘋狂地進行了優(yōu)化，因此確實是時候?qū)?NET JIT編譯器進行一些微優(yōu)化了。啟用優(yōu)化后，我的性能提高了約30％！這使我想起了我不久前在網(wǎng)上閱讀的一個故事。

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

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

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

4.看大局

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

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

5.內(nèi)存位置很重要

假設我們有一個數(shù)組數(shù)組。實際上是一張桌子，尺寸為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++;          }    }}

回答？第一個。在我的測試中，此循環(huán)使性能提高了8倍！

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

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

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

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

問題是沒有免費的午餐

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

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

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

第一行創(chuàng)建了一個完全無用的列表實例，因為下一行返回另一個實例并將其引用分配給變量。現(xiàn)在想象一下上面的兩行是否在一個執(zhí)行數(shù)千次的循環(huán)中？

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

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

7.不要使用空的析構函數(shù)

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

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

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

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

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

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

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

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

9.當心字符串連接

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

提防串聯(lián)大量字符串，尤其是在循環(huán)內(nèi)部

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

10.隨時關注C＃的發(fā)展

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

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

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

C＃性能很重要！

這只是我發(fā)現(xiàn)對提高.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