C#提升效能的幾點提示和技巧

語言: CN / TW / HK

C#效能提示和技巧

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中,字串是不可變的。因此,每次執行一些看起來好像在更改字串的操作時,它們都會建立一個新的字串。這些操作包括類似的方法 ReplaceSubstring ,同時也串聯。

提防串聯大量字串,尤其是在迴圈內部

因此,這裡的技巧很簡單-注意不要串聯大量字串,尤其是在迴圈內部。在這種情況下,請使用 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