性能差はないと思います。実際、生成されたコードは同じであり、こちらのドキュメントに従って-g
使用できます。また、デバッグ シンボルはコードに書き込まれるのではなく、「デバッグ セクション」と呼ばれる別のセクションに書き込まれます。このセクションは、実行時に (デバッガーによってのみ) 読み込まれることさえありません。-O
-g
実行される最適化や生成されるコードは変更されません。ここに記載されているように、これはgccポリシーです
ただし、同じドキュメントに次のように記載されていることに注意してください。
最適化されたコードが取ったショートカットは時として驚くべきものかもしれません: 宣言したいくつかの変数はまったく存在しないかもしれません。制御フローは、予期しない場所に一時的に移動する可能性があります。一部のステートメントは、一定の結果を計算するか、その値が既に手元にあるために実行されない場合があります。一部のステートメントは、ループの外に移動されているため、別の場所で実行される場合があります。それでも、最適化された出力をデバッグすることは可能です。これにより、バグがある可能性のあるプログラムに対してオプティマイザーを使用することが合理的になります。
したがって、最終的にはデバッグによって最適化が損なわれることはありませんが、逆は誤りであり、使用-O3
するとデバッグ情報が低下する可能性があります (たとえば、役に立たない変数を削除することによって)。
その場合は、次のように使用する方がよい場合があることに注意してください-Og
(ここで説明されているように)。
デバッグ エクスペリエンスを最適化します。-Og は、デバッグを妨げない最適化を有効にします。これは、標準の編集 - コンパイル - デバッグ サイクルに最適な最適化レベルである必要があり、高速なコンパイルと優れたデバッグ エクスペリエンスを維持しながら、適切なレベルの最適化を提供します。
ただし、これはパフォーマンスに影響を与えます。これは、デバッグに干渉する一部の最適化パスが実行されないためです。
編集:
リンクと引用符は、 に関する質問に答えますgcc
。. clang
ただし、 のドキュメントもいくつか見つけましたclang
。たとえば、ここに:
基本的に、デバッグ情報を使用すると、「-O0 -g」を使用してプログラムをコンパイルし、完全なデバッグ情報を取得して、デバッガーから実行するときにプログラムを任意に変更できます。「-O3 -g」を使用してプログラムをコンパイルすると、常に利用可能で正確な読み取り用の完全なデバッグ情報が得られます (たとえば、テール コールの削除とインライン化にもかかわらず、正確なスタック トレースが得られます)。プログラムから最適化された関数、または完全にインライン化された関数を呼び出します。