オプションの名前は何かを伝えますが、Visual Studio/コンパイラが実際に何を行い、実際の結果は何ですか?
編集: Google で検索すると、このアドレスを見つけることができますが、それは私が実際に探しているものではありません。本当のことが起こっているのだろうか。たとえば、なぜループの時間が短くなるのかなど。
51792 次
3 に答える
65
最適化を行わないと、コンパイラは非常に馬鹿げたコードを生成します。各コマンドは非常に単純な方法でコンパイルされるため、意図したとおりに実行されます。デバッグ ビルドでは、最適化がデフォルトで無効になっています。これは、最適化を行わないと、生成された実行可能ファイルがソース コードと簡単に一致するためです。
レジスタに保持される変数
最適化をオンにすると、コンパイラは多くの異なる手法を適用して、同じことをしながらコードを高速に実行します。Visual C++ での最適化されたビルドと最適化されていないビルドの最も明白な違いは、変数値が最適化されたビルドでは可能な限り長くレジスタに保持されるのに対し、最適化されていない場合は常にメモリに格納されるという事実です。これはコード速度だけでなく、デバッグにも影響します。この最適化の結果として、デバッガーは、コードをステップ実行しているとき、変数値を確実に取得できません。
その他の最適化
/O オプション (コードの最適化) MSDN ドキュメントで説明されているように、コンパイラによって適用される他の複数の最適化があります。さまざまな最適化手法の一般的な説明については、Wikipedia Compiler Optimization articleを参照してください。
于 2008-09-22T10:00:40.907 に答える
18
ポール・ヴィックのブログから：
デバッグを支援するために発行するであろう NOP 命令を削除します。最適化がオフの場合 (およびデバッグ情報がオンの場合)、コンパイラは、実際の IL が関連付けられていないが、ブレークポイントを配置する必要がある行に対して NOP 命令を発行します。このようなものの最も一般的な例は、「If」ステートメントの「End If」です。End If に対して発行される実際の IL はないため、NOP を発行しません。デバッガーはブレークポイントを設定できません。その上で。最適化を有効にすると、コンパイラは NOP を出力しなくなります。
生成された IL の単純な基本ブロック分析を実行して、デッド コード ブロックを削除します。つまり、各メソッドを分岐命令で区切られた IL のブロックに分割します。ブロックの相互関係を簡単に分析することで、分岐がないブロックを特定できます。したがって、決して実行されずに省略できるコード ブロックを見つけ出し、アセンブリをわずかに小さくすることができます。また、この時点でいくつかの小さな分岐の最適化も行います。たとえば、別の GoTo ステートメントを GoTo する場合、最初の GoTo を最適化して 2 番目の GoTo のターゲットにジャンプするだけです。
IsJITOptimizerDisabled を False に設定して DebuggableAttribute を出力します。基本的に、これにより、ランタイム JIT は、コードの並べ替えやインライン化など、適切と思われる方法でコードを最適化できます。これにより、より効率的で小さなコードが生成されますが、コードをデバッグしようとすると非常に困難になる可能性があることを意味します (試した人なら誰でも言うように)。JIT 最適化が何であるかの実際のリストは、私にはわかりません。おそらく、Chris Brumme のような誰かが、この問題について何らかの時点で意見を述べるでしょう。要するに、最適化スイッチを使用すると最適化が有効になり、ブレークポイントの設定やコードのステップ実行が難しくなる可能性があります。
于 2008-09-22T10:03:04.863 に答える
2
簡単に言えば、-Ox を使用して、コンパイラにその仕事をさせます。
長い答え: さまざまな種類の最適化の効果を正確に予測することは不可能です。高速なコードを最適化すると、実際にはサイズを最適化する場合よりも小さなコードが生成されることがあります。本当に最後の 0.01% のパフォーマンス (速度またはサイズ) を取得したい場合は、さまざまなオプションの組み合わせをベンチマークする必要があります。
また、最近のバージョンの Visual Studio には、リンク時の最適化やプロファイルに基づく最適化など、より高度な最適化のオプションがあります。
于 2008-09-22T09:14:56.477 に答える