-g gccフラグを使用してコンパイルしたプログラムは、-gを使用せずにコンパイルした同じプログラムよりも遅くなりますか？
パフォーマンスのために-O3を、デバッグシンボルのために-gを使用してプログラムをコンパイルしています（クラッシュの場合は、コアダンプを使用できます）。 1つ気になるのは、-gオプションを使用するとパフォーマンスが低下することですか。 -gを使用した場合と使用しない場合のコンパイルの出力を見ると、-gを使用しない場合の出力は、-gを使用した場合のコンパイルの出力よりも80％小さいことがわかります。デバッグシンボルのために余分なスペースが使用される場合、この部分はランタイム中に使用されないので、私はそれを気にしません（多分）。ただし、-gを使用しないコンパイル出力の各命令について、-gを使用してコンパイル出力でさらに4つの命令を実行する必要がある場合は、コアダンプを処理できないという犠牲を払ってでも、-gオプションの使用を停止することをお勧めします。
プログラム内のデバッグシンボルセクションのサイズを知る方法と、一般に-gを使用してコンパイルすると、-gを使用せずにコンパイルされた同じコードよりも実行速度が遅いプログラムが作成されますか？
gccドキュメント からの引用
GCCでは、-gを-Oとともに使用できます。最適化されたコードが使用するショートカットは、驚くべき結果をもたらすことがあります。宣言した一部の変数がまったく存在しない場合があります。制御の流れは、予期しないところに一時的に移動する場合があります。一部のステートメントは、定数の結果を計算するため、またはそれらの値がすでに手元にあるため、実行されない場合があります。一部のステートメントは、ループの外に移動されたため、別の場所で実行される場合があります。
つまり：
私はあなたのためにデバッグシンボルを挿入しますが、最適化パスがそれらを台無しにした場合、それらを保持しようとはしません、あなたはそれに対処する必要があります
デバッグシンボルはコードに書き込まれませんが、「デバッグセクション」と呼ばれる別のセクションに書き込まれます。このセクションは、実行時にロードされません（デバッガーによってのみ）。つまり、コードは変更されません。コード実行速度のパフォーマンスの違いに気付くべきではありませんが、ローダーがより大きなバイナリを処理する必要がある場合、または何らかの方法でバイナリサイズの増加を考慮している場合は、速度が低下する可能性があります。特定のケースで100％確実になるように、アプリをベンチマークする必要があるでしょう。
Gcc 4.8の 別のオプション もあることに注意してください。
-Ogデバッグエクスペリエンスを最適化します。
-Ogは、デバッグを妨げない最適化を有効にします。これは、標準の編集、コンパイル、デバッグのサイクルに最適な最適化レベルであり、高速なコンパイルと優れたデバッグエクスペリエンスを維持しながら、妥当なレベルの最適化を提供します。
このフラグは、デバッグ情報に干渉するすべての最適化パスを無効にするため、パフォーマンスに影響します。
最後に、特定のプロセッサに最適化するように指示されない限り、一部の最適化が別のアーキテクチャよりも特定のアーキテクチャに適している場合があります偶数。 march/mtune アーキテクチャのオプション）、O3ではgccが汎用アーキテクチャに最適です。つまり、一部の不自然なシナリオでは、O3がO2よりも遅くなることさえあります。 「ベストエフォート」は、必ずしも「ベストなもの」を意味するわけではありません。