[[428811]]

本文轉(zhuǎn)載自微信公眾號(hào)「DotNET技術(shù)圈」，作者Raygun 。轉(zhuǎn)載本文請聯(lián)系DotNET技術(shù)圈公眾號(hào)。

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

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

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

1.每個(gè)開發(fā)人員都應(yīng)使用分析器

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

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

沒有

正確地拾取它)。

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

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

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

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

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

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

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

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

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

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

知道團(tuán)隊(duì)總是沒有足夠的空間，因?yàn)槟抢镉锌捎玫膬?nèi)存，就可以為團(tuán)隊(duì)提供他們所需要的東西，并按時(shí)發(fā)貨。

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

4.看大局

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

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

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

假設(shè)我們有一個(gè)數(shù)組數(shù)組。實(shí)際上是一張桌子，尺寸為3000×3000。我們要計(jì)算有多少個(gè)插槽的值大于零。

問題–這兩個(gè)中哪個(gè)更快?

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++; 
          } 
    } 
} 

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

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

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

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

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

問題是沒有免費(fèi)的午餐

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

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

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

第一行創(chuàng)建了一個(gè)完全無用的列表實(shí)例，因?yàn)橄乱恍蟹祷亓硪粋€(gè)實(shí)例并將其引用分配給變量。現(xiàn)在想象一下上面的兩行是否在一個(gè)執(zhí)行數(shù)千次的循環(huán)中?

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

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

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

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

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

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

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

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

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

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

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

9.當(dāng)心字符串連接

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

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

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

10.隨時(shí)關(guān)注C#的發(fā)展

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

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

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

C#性能很重要!

這只是我發(fā)現(xiàn)對提高.NET代碼性能有用的幾件事的集合-但是值得花時(shí)間檢查代碼以確保其性能。您的團(tuán)隊(duì)和客戶將感謝您!

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] 許多有用的技術(shù)可以避免對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