在調試和發佈模式下構建的.NET程序集的性能差異？

Question

一些以前的開發人員將一些以調試模式構建的組件投入生產。是否值得在發佈模式下重新編譯它們並重新部署它們？如果只有1-2％的表現增加，我可能會把他們留在那裏。另一方面，增加10-20％可能會改變我的想法。

Answer 1

我在一年前有過同樣的問題，因爲我們在生產中遇到了主要的性能問題。正如MS向我解釋的那樣，調試版本包含調試鉤子，這可能導致內存消耗增加大約1-10％，具體取決於應用程序的功能。

如果你沒有問題，然後讓他們獨立，但如果您有內存消耗問題，然後繼續前進，重新編譯/部署。

Answer 2

以我的經驗，我看到了30-40％的差異。這是DotNetZip，一個加密，壓縮和一個小文件I/O的庫。超過85％的時間花在加密和壓縮上，只是移動字節。

Answer 3

反對使用調試另一種說法建立在生產是因爲由於需要調試符號被加載它們消耗更多的內存。

Answer 4

一般來說，你會看到一個好處，因爲發行版本通常與使用/optimize編譯器選項優化編譯。但是，差異有多大將取決於您的特定裝配 - 您需要進行配置。

Answer 5

我發現的性能差異與代碼的複雜性成倍增加 - 一個簡單的應用程序可能只看到5％的差異，但我已經看到了，也取決於複雜的應用，特別是那些50％的增速放緩涉及像數組或地圖這樣的更大的數據結構。

當然還有的可能性，調試代碼可能會略有不同，以及，這取決於你如何設置 - 看斷言例如。

Answer 6

值得注意的是，該版本代碼也刪除了一些預處理東西，如：

#if DEBUG 
... 
#endif 

它也消除的Debug.WriteLine，Debug.Assert的，在System.Diagnostics命名空間中一些其他的東西，它可以是在測試中非常有用，但是對於發佈版本，設計良好的代碼沒有意義。

Answer 7

如果您查看爲調試和發佈生成的IL代碼，差異通常很小。大部分差異在於主要源點的附加nop命令，以支持編輯和繼續以及源代碼調試。但是，當.NET運行時實際上將MSIL運行時，運行時程序集幾乎是相同的。調試器連接時最大的不同。這將阻止JIT優化實際運行代碼。

發行版本通常要小得多，因爲它們只包含不多的代碼。可以使用#if DEBUG語句以及指示編譯器省略對發佈模式中的方法的調用的條件屬性（如Debug.WriteLine）包圍代碼塊。

我發現的Debug.WriteLine和Trace.WriteLine方法，在生產代碼左，具有即使調試器沒有連接一個顯著的性能影響時。