アプリケーションプロファイリングの結果を表示するためのテキストベースのアプリケーションについて知っていますか？プロファイリング結果には、基本的にC++関数呼び出しのバックトレースのリストと、これらのバックトレースが発生した頻度が含まれています。今では、生データ（バックトレースが最も頻繁に発生した機能、最も頻繁に呼び出された機能、コールトレースとは独立した機能...）を分析するためのコンソールツールを探しています。プロファイリング結果のテキストベースのビューア
これまでのところ、生データからcallgrind互換のファイルを作成し、解析に優れたKCachegrindツールを使用しました。しかし、今では、テキストベースの端末を使わずに動作するツールも探しています。何か案は？
callgrind_annotateをご覧ください。
このコマンドはプロファイルデータを読み込み、必要に応じてソースアノテーションを使用してソートされた関数のリストを出力します。
私はこのようなビューアを一度書きました。これはコード行に焦点を当て、その行を実行しているサンプルの割合と、上位または下位のコード行への遷移を許可するバタフライ表示を示します。
素晴らしいデモができましたが、実際に使ったのですか？長い間ではありません。
（私は、スタックのサンプルは、ユーザーの待機中につまり、あなたがスピードアップしたい間隔の間にないとられていると仮定しています。）
事は、プログラムは、おそらくその中で無駄な何かをやっていますさ時間。 （そうでない場合、速度を上げることはできません） その無駄なことは何でも、10％、50％、90％などのような貧弱な理由のために費やされる時間は、何パーセントかで構成されます。その間、スタック上にあるので、スタックサンプルを調べるとそのサンプルが表示されます。
そして、非常に多く見る必要はありません。何かが50％の時間を費やしているとすれば、1000のサンプルは約500で表示され、10のサンプルは約5で表示されます。サンプルの数が多いほど精度が1桁高くなります。問題を分離して修正できるようにすることが目的の場合は、余分な数字は必要ありません。
したがって、その行を通過するスタックサンプルのパーセントを示すツールは、無駄なコードがその行に表示され、パーセンテージを示すため、持っているのは非常に良いことです。
ステートメントが実行されている理由がわかりません。これは、無駄であるかどうかを知る方法です。スタック上のステートメントのコンテキストを見ると、そのことが分かります。
私はビューアを持っていたにもかかわらず、サンプル自体を調べるだけで終わったばかりで、サンプル数は約10〜20個しかありませんでした。パーセンテージが大きければ大きいほど、見つけ出す前に見る必要があるサンプル数が少なくなります。 Here's an example.