首頁猿問調(diào)試和發(fā)布版本之間的性能差異

調(diào)試和發(fā)布版本之間的性能差異

C# .NET

MM們 2019-06-12 15:00:41

調(diào)試和發(fā)布版本之間的性能差異我必須承認(rèn)，我通常不會在調(diào)試和釋放配置在我的程序中，我通常選擇使用調(diào)試配置，即使在客戶端實際部署程序時也是如此。據(jù)我所知，如果不手動更改這些配置，唯一的區(qū)別是調(diào)試有.DEBUG常量定義，以及釋放有.優(yōu)化代碼檢查過了。所以我的問題有兩個：這兩種配置之間是否存在很大的性能差異。是否有任何特定類型的代碼會導(dǎo)致性能上的巨大差異，或者它實際上并不那么重要？是否有任何類型的代碼在調(diào)試可能在以下情況下失敗的配置釋放配置，或者您是否可以確定在調(diào)試在發(fā)行版配置下，配置也可以很好地工作。

查看完整描述

3 回答

MMMHUHU

TA貢獻(xiàn)1834條經(jīng)驗獲得超8個贊

在發(fā)行版構(gòu)建中，C#編譯器本身并不會更改所發(fā)出的IL。值得注意的是，它不再發(fā)射NOP操作碼，允許您在卷曲大括號上設(shè)置斷點。最大的一個是內(nèi)置在JIT編譯器中的優(yōu)化器。我知道它進(jìn)行了以下優(yōu)化：

方法襯里。將方法調(diào)用替換為注入該方法的代碼。這是一個很大的問題，它使屬性訪問器基本上是免費的。
CPU寄存器分配。局部變量和方法參數(shù)可以保存在CPU寄存器中，而不會(或不太頻繁)存儲回堆棧幀。這是一個很大的問題，因為它使得調(diào)試優(yōu)化代碼變得如此困難。并給出易揮發(fā)關(guān)鍵字的意思。
數(shù)組索引檢查消除。處理數(shù)組時的一個重要優(yōu)化(所有.NET集合類都在內(nèi)部使用數(shù)組)。當(dāng)JIT編譯器可以驗證一個循環(huán)從不索引超出界限的數(shù)組時，它將消除索引檢查。大的。
循環(huán)展開。通過在主體中重復(fù)代碼4次并減少循環(huán)，可以改進(jìn)具有小體的循環(huán)。降低了分支成本，并改進(jìn)了處理器的超標(biāo)量執(zhí)行選項。
死代碼消除。如if(False){/.../}被完全淘汰。這可能是由于不斷的折疊和內(nèi)襯。其他情況是JIT編譯器可以確定代碼沒有可能產(chǎn)生副作用。這種優(yōu)化使得分析代碼變得如此棘手。
代碼提升。循環(huán)中不受循環(huán)影響的代碼可以從循環(huán)中移出。C編譯器的優(yōu)化器將花費更多的時間來尋找提升的機(jī)會。然而，這是一個昂貴的優(yōu)化，因為需要的數(shù)據(jù)流分析和抖動無法負(fù)擔(dān)的時間，所以只有提升明顯的情況。迫使.NET程序員編寫更好的源代碼并提升自己。
常見的子表達(dá)式消除。x=y+4；z=y+4；變成z=x；在語句中非常常見，如DEST[ix+1]=src[ix+1]；為可讀性而編寫，而不引入輔助變量。不需要妥協(xié)可讀性。
不斷折疊。x=1+2；變成x=3；這個簡單的示例被編譯器提前捕獲，但在JIT時發(fā)生，而其他優(yōu)化使得這成為可能。
復(fù)制傳播。x=a；y=x；變成y=a；這有助于寄存器分配器做出更好的決定。這在x86抖動中是一個很大的問題，因為它幾乎沒有什么寄存器可以使用。讓它選擇正確的選擇是Perf的關(guān)鍵。

這些是非常重要的優(yōu)化，可以使太棒了例如，當(dāng)您分析應(yīng)用程序的Debug構(gòu)建并將其與發(fā)布版本進(jìn)行比較時，會有很大的不同。但真正重要的是，當(dāng)代碼處于關(guān)鍵路徑時，您編寫的5%至10%的代碼其實影響您程序的Perf。JIT優(yōu)化器不夠聰明，無法預(yù)先知道什么是關(guān)鍵，它只能為所有代碼應(yīng)用“將其轉(zhuǎn)換為11”撥號。

這些優(yōu)化對程序執(zhí)行時間的有效結(jié)果通常會受到其他地方運行的代碼的影響。讀取文件、執(zhí)行dBASE查詢等。JIT優(yōu)化器使工作完全不可見。不過，它并不介意：)

JIT優(yōu)化器是相當(dāng)可靠的代碼，主要是因為它已經(jīng)被測試了數(shù)百萬次。在程序的發(fā)布版本中出現(xiàn)問題是非常罕見的。但這確實發(fā)生了。x64和x86抖動在結(jié)構(gòu)上都有問題。x86抖動存在浮點一致性問題，當(dāng)浮點計算的中間部分保持在80位精度的FPU寄存器中，而不是在刷新到內(nèi)存時被截斷時，會產(chǎn)生微妙的不同結(jié)果。

反對回復(fù) 2019-06-12

長風(fēng)秋雁

TA貢獻(xiàn)1757條經(jīng)驗獲得超7個贊

是的，有許多性能差異，這些都適用于您的代碼。調(diào)試很少進(jìn)行性能優(yōu)化，并且發(fā)布模式非常多；
只有依賴于DEBUG常數(shù)在發(fā)行版構(gòu)建中可能執(zhí)行不同的操作。除此之外，你不應(yīng)該看到任何問題。

依賴于DEBUG常數(shù)是Debug.Assert()方法，該方法具有以下屬性[Conditional("DEBUG)"]定義。這意味著它也依賴于DEBUG常量，而這并不包括在發(fā)行版構(gòu)建中。

反對回復(fù) 2019-06-12

慕標(biāo)琳琳

TA貢獻(xiàn)1830條經(jīng)驗獲得超9個贊

這在很大程度上取決于應(yīng)用程序的性質(zhì)。如果您的應(yīng)用程序是UI密集型的，您可能不會注意到任何不同，因為連接到現(xiàn)代計算機(jī)的最慢的組件是用戶。如果您使用一些UI動畫，您可能需要測試在調(diào)試構(gòu)建中運行時是否會發(fā)現(xiàn)任何明顯的滯后。

但是，如果您有許多計算量很大的計算，那么您會注意到差異(正如Pieter所提到的那樣，差異可能高達(dá)40%，盡管這將取決于計算的性質(zhì))。

這基本上是一種設(shè)計上的權(quán)衡。如果您在調(diào)試版本下發(fā)布，那么如果用戶遇到問題，您可以得到更有意義的跟蹤，并且可以進(jìn)行更靈活的診斷。通過在調(diào)試版本中發(fā)布，還可以避免優(yōu)化器產(chǎn)生模糊。海生蟲.

反對回復(fù) 2019-06-12