prof - プロファイルデータの表示
prof [-ChsVz] [-a | c | n | t] [-o | x] [-g | l] [-m mdata]
[prog]
prof コマンドは、monitor 関数によって生成されるプロファイルファイルを解釈します。オブジェクトファイル prog (デフォルトでは a.out) のシンボルテーブルが読み込まれ、プロファイルファイル (デフォルトでは mon.out) と関係付けされます。外部テキストシンボルごとに、そのシンボルのアドレスと次のシンボルのアドレスの間までの実行に費やされた時間の割合が、その関数が呼び出された回数と、呼び出し 1 回当たりの平均時間 (ミリ秒単位) と一緒に出力されます。
相互排他的なオプション –a、–c、–n、および –t によって、出力行のソートのタイプが決定されます。
シンボルアドレスの昇順でソートします。
呼び出し数の降順でソートします。
シンボル名の字句によってソートします。
合計時間の割合の降順でソートします (デフォルト)。
相互排他的なオプション –o および –x は、モニターされた各シンボルのアドレスの出力を指定します。
各シンボルアドレス (8 進数) とシンボル名を一緒に出力します。
各シンボルアドレス (16 進数) とシンボル名を一緒に出力します。
相互排他的なオプション –g および –l は、報告されるシンボルのタイプを制御します。–l オプションは慎重に使用する必要があります。これは、静的関数に費やした時間を前の (メモリー内の) グローバル関数に適用するのであって、静的関数に対してレポート内で別のエントリを立てるわけではありません。すべての静的関数が適切に配置されている場合、この機能は非常に便利です。そうではない場合、結果のレポートは誤解を招く可能性があります。
かりに、A と B がグローバル関数で、A のみが静的関数 S を呼び出すとします。S がソースコード内で A の直後に配置されている (つまり S が正しく配置されている) 場合、–l オプションを使用することで、A に費やされる時間量は、S に費やされる時間を含めて簡単に判定できます。ただし、A と B の両方が S を呼び出す場合に –l オプションが使用されると、レポートは誤解を与えます。B が S を呼び出す間に費やされる時間は A に加算されるため、実際よりも多くの時間が A に費やされたかのように表示されます。この場合、関数 S を正しく配置することはできません。
静的 (非大域) 関数に費やされた時間を別々にリストします。–g オプション関数は –l の関数の逆です。
静的に宣言された関数の出力を抑制します。このオプションが指定された場合、静的関数の実行に費やした時間は、実行可能ファイル内の静的関数の前にロードされたもっとも近いグローバル関数に割り当てられます。このオプションはデフォルトです。これは –g 関数の逆であり、慎重に使用する必要があります。
次のオプションは任意に組み合わせて使用できます。
C++ シンボル名を出力する前に復号化します。
レポートに通常出力されているヘッダーを抑制します。これは、レポートをさらに処理する場合に便利です。
入力プロファイルファイルとして mon.out の代わりにファイル mdata を使用します。
モニタリングパラメータおよび統計の複数のサマリーを標準エラー出力に出力します。
標準エラー出力に prof バージョン情報を出力します。
コール数がゼロでゼロ時間に関連付けられている場合でも、プロファイル範囲内のすべての記号を含めます。
MARK マクロを使用したプロファイリングのために、単一の関数がサブ関数に分割されることがあります。prof(5) を参照してください。
プロファイルされたプログラムによって作成されるファイルの名前は、環境変数 PROFDIR で制御されます。PROFDIR が設定されない場合、プログラムの終了時点の現行ディレクトリに mon.out が生成されます。PROFDIR= string の場合、string/pid.progname が生成されます。ここで、progname はパス接頭辞が削除された argv[0] で構成され、pid はプログラムのプロセス ID です。PROFDIR が設定されていても NULL の場合、プロファイリング出力は生成されません。
デフォルトのプロファイルファイル
デフォルトの名前リスト (オブジェクト) ファイル
属性についての詳細は、マニュアルページの attributes(5) を参照してください。
|
gprof(1), exit(2), pcsample(2), profil(2), malloc(3C), malloc(3MALLOC), monitor(3C), attributes(5), prof(5)
実行可能イメージが取り除かれ、.symtab シンボルテーブルがない場合、gprof はグローバル動的シンボルテーブル .dynsym および .SUNW_ldynsym (存在する場合) を読み込みます。動的シンボルテーブル内のシンボルは、.symtab にあるシンボルのサブセットです。.dynsym シンボルテーブルには、ランタイムリンカーによって使用されるグローバルシンボルが含まれています。.SUNW_ldynsym は .dynsym の情報をローカル関数のシンボルで拡張します。.dynsym が見つかって .SUNW_ldynsym が見つからない場合は、グローバルシンボルの情報のみを使用できます。ローカルシンボルがない場合、動作は –a オプションの説明と同じです。
同一の実行を連続して行なったときに報告される時間が異なる場合があります。これは、ほかのプロセスとキャッシュを共有したことによってキャッシュヒット率が変化したためです。マシンを使用しているプログラムが 1 つのみのように見えていても、隠れているバックグラウンドプロセスまたは非同期プロセスがデータに影響することがあります。まれに、プログラムの記録を開始するクロックティックがプログラムのループに影響して測定が大幅に歪むことがあります。ただし、呼び出し回数は常に正確に記録されます。
monitor への最後の呼び出しが明示的にコーディングされていない場合、プロファイルファイルの生成が保証されるのは、exit を呼び出すプログラムまたは main から戻るプログラムのみです。
–g オプションが使用されない場合、静的関数に対する時間は前の外部テキストシンボルに加算されます。ただし、前の関数の呼び出し回数は正しいままです。つまり、静的関数の呼び出し回数は、外部関数の呼び出し回数に追加されません。
–t、–c、–a、および –n のうち複数が指定さた場合、最後に指定されたオプションが使用され、警告が表示されます。
プロファイリングするプログラムをコンパイルするときに、LD_LIBRARY_PATH に /usr/lib をコンポーネントとして含めないでください。LD_LIBRARY_PATH に /usr/lib が含まれている場合、プログラムは /usr/lib/libp のプロファイリングバージョンのシステムライブラリと正しくリンクされません。gprof(1) を参照してください。
mcount()、_mcount()、moncontrol()、_moncontrol()、monitor()、_monitor() などの関数が prof レポートに表示される場合もあります。これらの関数はプロファイリングの実装の一部であり、実行時のオーバーヘッドが多少あります。これらの関数はプロファイルされていないアプリケーションにはないため、アプリケーションのパフォーマンスを評価する場合、これらの関数の累積時間および呼び出し回数は無視できます。
64 ビットのプロファイリングは、動的にリンクされた実行可能ファイルで自由に使用できます。オブジェクトがプロファイリング用にコンパイルされている場合は、共有オブジェクトのプロファイリング情報が収集されます。ほかの共有オブジェクトのシンボルが同じ名前である可能性があるため、プロファイルの出力を解釈するときに注意する必要があります。重複した名前がプロファイル出力に表示される場合、重複している各シンボルの前にモジュール ID の接頭辞を付ける、–s (サマリー) オプションを使用することをお勧めします。シンボルはサマリー内のモジュール情報を確認することで、適切なモジュールにマップできます。
動的にリンクされた実行可能ファイルと一緒に –a オプションが使用される場合、共有オブジェクト単位でソートが発生します。異なる共有オブジェクトからのシンボルが同じ値を持つ可能性が高いため、この方法により、理解しやすい出力が得られます。–s オプションが指定された場合、異なる共有オブジェクトからのシンボルは、空白行で区切られます。
32 ビットプロファイリングは動的にリンクされた実行可能ファイルに使用できますが、注意する必要があります。32 ビットプロファイリングでは、prof を使用して共有オブジェクトのプロファイルを作成することはできません。このため、プロファイルされた動的にリンクされたプログラムを実行すると、イメージの main の部分のみが標本収集されます。これは、main オブジェクトの外部で費やされたすべての時間 (つまり、共有オブジェクトで費やされた時間) は、プロファイルサマリーに含められないことを意味し、プログラムで報告される合計時間が、プログラムによって使用された合計時間より少ない場合があります。
共有オブジェクト内で費やされる時間を計上できないため、prof を使用してプログラムのプロファイルを作成する場合は常に、共有オブジェクトの使用を最小限にする必要があります。必要な場合は、プログラムを共有オブジェクトではなくプロファイルされたバージョンのライブラリ (またはプロファイリングバージョンがない場合は、標準のアーカイブバージョン) にリンクして、ライブラリの関数のプロファイル情報を取得してください。プロファイルされたライブラリのバージョンは、システムの /usr/lib/libp ディレクトリに配置されている場合があります。プロファイリングについては、コンパイラドライバのドキュメントを参照してください。
極端な場合を考えてみます。共有 C ライブラリと動的にリンクされたプロファイルされたプログラムが、いくつかの libc ルーチン (malloc() など) で 100 単位時間を費やします。malloc() はルーチン B からのみ呼び出され、B は 1 単位時間のみを消費するとします。さらに、ルーチン A は、イメージの main (プロファイルされている) 部分のほかのどのルーチンよりも多い 10 単位時間を消費するとします。この場合、prof では、ほとんどの時間が A に費やされ、B に費やされる時間はほとんどないと結論づけられます。このことから、ルーチン A ではなくルーチン B を調査することによって大きな改善を望むのは、ほとんど不可能です。この場合のプロファイラの値は非常に劣化しています。これを解決するには、プロファイリングにアーカイブをできるかぎり使用します。