Visual Studioビルドの「コードの最適化」オプションの利点
C＃リリースコードの多くは、[コードの最適化]オプションをオフにしてビルドされています。これは、リリースモードでビルドされたコードをより簡単にデバッグできるようにするためだと思います。
バックエンドWebサービスに接続するかなり単純なデスクトップソフトウェア（つまり、特にプロセッサ集中型のアプリケーションではない）を作成しているとすると、何らかのパフォーマンスヒットが予想されるとしたらどうでしょうか。
また、特定のプラットフォームに悪影響が及ぶ可能性はありますか？例えば。マルチプロセッサ/ 64ビット。
詳細は http://blogs.msdn.com/jaybaz_ms/archive/2004/06/28/168314.aspx にあります。
簡単に言うと...
マネージコードでは、ランタイムのJITterがほぼすべての最適化を行います。このフラグから生成されたILの違いはかなり小さいです。
「パフォーマンスヒット」の質問に答えられるのはあなただけです。両方の方法を試して、パフォーマンスを測定し、何が起こるかを確認してください。ヒットは巨大な場合もあれば、存在しない場合もあります。これを読んだ人は、あなたにとって「巨大」が1マイクロ秒を意味するのか20分を意味するのかを知りません。
最適化スイッチがオンになっているときに、ジッターではなく、C＃コンパイラーによってどの最適化が行われるかに興味がある場合は、以下を参照してください。
http://blogs.msdn.com/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx
実際、違いがあり、時にはかなり重要です。パフォーマンスに実際に影響する可能性があるもの（JITが完全に処理しないものであるため）：
- 不要なローカル変数（各呼び出しのスタックフレームが大きいなど）
- 一般的な条件付き命令であるJITは、非常に簡単な方法でそれらを変換します。
不要な分岐（JITでも十分に機能しない-結局のところ、すべてのスマートな最適化を実行するのに時間はかかりません）
したがって、数値的なことをしている場合は、最適化をオンにします。それ以外の場合は、まったく違いがわかりません。
コンパイラーによって行われる最適化はかなり低レベルであり、ユーザーのエクスペリエンスに影響を与えません。
アプリケーションの最適化を定量化したい場合は、最適化されていないビルドと最適化されたビルドのプロファイルを作成し、結果を比較するだけです。
複雑でCPUを集中的に使用するコード（使用しているコードは、コンピューターを100％使用するのに十分なスレッドを生成できるモンテカルロシミュレーションです。これは36コア環境でテストされています）のパフォーマンスヒットは最大4です。倍以上！ 2時間かかるシミュレーションは、最適化フラグなしで約9時間かかります。 （パスは約500,000で、各パスには、各オブジェクトで非常に複雑な計算を行う約2000の異なるオブジェクトに対して500ステップがあります）。