デバッグとリリースモードでビルドされた.NETアセンブリのパフォーマンスの違いはありますか？

Question

以前の開発者の中には、デバッグモードでビルドされたアセンブリの一部を本番環境に組み込むものがありました。それらをリリースモードで再コンパイルして再デプロイする価値はありますか？ 1〜2％の性能向上があれば、そこに残すだけです。一方、10〜20％の増加は私の心を変えるかもしれません。

Answer 1

私たちは生産上の大きなパフォーマンス上の問題を抱えていたため、これは1年前と同じ質問です。 MS Premierのサポートから私に説明されていたように、デバッグビルドバージョンにはデバッグ用のフックが含まれているため、アプリケーションの機能に応じてメモリ消費量が約1〜10％増加する可能性があります。

問題が発生していない場合はそのままにしておきますが、メモリ消費に問題がある場合は、先に進んで再コンパイル/デプロイしてください。

Answer 2

私の経験では、30-40％の違いが見られました。これはDotNetZipであり、暗号化、圧縮、およびファイルI/Oが少ないライブラリです。 85％以上の時間が暗号化と圧縮に費やされ、バイトを動かすだけでした。

Answer 3

デバッグシンボルをロードする必要があるため、デバッグビルドを本番環境で使用することについてのもう1つの議論は、より多くのメモリを消費するためです。

Answer 4

通常、リリースバージョンは/optimizeコンパイラオプションを使用して最適化されてコンパイルされるため、利点があります。ただし、その差異の大きさは、特定のアセンブリによって異なります。プロファイルする必要があります。

Answer 5

私は、コードの複雑さによって指数関数的に増加することを発見しました。単純なアプリケーションでは5％の差しか見られないかもしれませんが、複雑なアプリケーション、特にアプリケーションでは50％配列や地図のようなより大きなデータ構造を必要とする。

設定の仕方によっては、デバッグコードも若干異なる可能性があります。たとえば、アサーションを見てください。

Answer 6

それは同様に、そのリリースコードはまた、いくつかのプリプロセッサのものを削除し、注目に値する：それはまたDebug.WriteLine、Debug.Assertの、とすることができたSystem.Diagnostics名前空間内のいくつかの他のものを削除し

#if DEBUG 
... 
#endif 

テストでは役に立ちますが、リリースビルド用にうまく設計されたコードでは無意味です。

Answer 7

DebugおよびReleaseビルド用に生成されたILコードを見ると、その差異は一般に小さいです。ほとんどの違いは、EditとContinue、およびソース行のデバッグをサポートするために、キーのソース・ポイントに追加のnopコマンドがあります。しかし、.NETランタイムが実際にMSILをJITするとき、ランタイムアセンブリはほとんど同じです。最も大きな違いは、デバッガが接続されている場合です。これにより、JITは実際の実行コードを最適化できなくなります。

リリースバージョンは、コードをあまり含まないため、多くの場合、かなり小さくなります。 #if DEBUGステートメントで囲まれたコードのパッチや、リリースモードのメソッド（Debug.WriteLineなど）をコンパイラに省略するようにコンパイラに指示する条件付き属性があります。

Debug.WriteLineおよびTrace.WriteLineメソッドは、本番用のコードに残しておけば、デバッガがアタッチされていない場合でもパフォーマンスに大きな影響を与えることがわかりました。