問題タブ [kcachegrind]

gprof両方でいくつかの C++ 数値計算コードをプロファイリングするkcachegrindと、実行時間 (入力に応じて 50 ～ 80%) に最も寄与する関数については同様の結果が得られますが、10 ～ 30% の間の関数については、これらのツールの両方で異なる結果が得られます。それらの1つが信頼できないということですか？ここで何をしますか？

さまざまなオプションで実行したときにプログラムのパフォーマンスがどのように変化するかを理解しようとしています.1.8 の係数を説明したいと思います. callgrind[valgrind] のツールでプロファイリングを行っており、 kcachegrindを使用して結果を視覚化しています。しかし、私は本当に違いを見たいと思っています。プログラムを見つけましたcg_diffが、callgrind プロファイルでは機能せず、cachegrind プロファイルでしか機能しません。これは収集するにはコストがかかりすぎます。 2 つのプロファイルの違いを視覚化するツールを知っている人はいますか?

Kcachegrindは、デフォルトでデフォルトの1つのobjdumpを使用します（ELFからasmコードを取得するため）。

Kcachegrindに別のobjdumpを使用させることは可能/home/os_gx/local/bin/arm-linux/objdumpですか？

kcachegrind で gprof の出力を表示するには? gcc の gmon.out から callgrind.out へのコンバーターはありますか?

重複の可能性:
Windows Callgrind 結果ブラウザー、KCacheGrind の代替

Windows 用の kcachegrind プロファイラーはありますか (完全な KDE をインストールする必要はありません)? または、そのフォーマットを読み取ってレンダリングできるもの:

• コールグラフ
• 注釈付きソース
• 注釈付き asm コード

ありがとう。

kcachegrind で解析した php スクリプトに xdebug プロファイルがあります。<cycle 1>これは、特定の関数内で費やされたほとんどの時間が内部で費やされ、上位の「呼び出し元」が index.php の「include」と「include_once」から作成されたことを示すスクリーンショットです。

このプロファイルは、Apache 'ab' を使用したスト​​レス テスト中に実行されたため、多くの同時接続が発生していました。

<cycle 1>xdebug プロファイルには何が表示されますか?

kcachegrind/callgrind が奇妙な結果を報告するモデル コードがあります。一種のディスパッチャー機能です。ディスパッチャーは 4 つの場所から呼び出されます。各呼び出しは、実行する実際のdo_J関数を示します（したがって、first2呼び出しのみdo_1などdo_2）

ソース (これは実際のコードのモデルです)

でコンパイルgcc -O0; コールグラインドvalgrind --tool=callgrind; kcachegrindedkcachegrindとqcachegrind-0.7.

以下は、アプリケーションの完全なコールグラフです。do_J へのすべてのパスはディスパッチャーを通過します。これは適切です (do_1 は速すぎるとして隠されていますが、実際にはここにあり、do_2 に残されています)。

誰がそれを呼び出したかに注目しdo_1て確認しましょう (この図は正しくありません)。

そして、これは非常に奇妙だと思いますが、すべてではfirst2ありません。outer2do_1

callgrind/kcachegrind の制限ですか? 重み付きで正確なコールグラフを取得するにはどうすればよいですか (すべての関数の実行時間に比例し、その子の有無にかかわらず)。

ここにリンクの説明を入力

こんにちは、Kcachegrind を使用して C コードをプロファイリングしています。しかし、コール グラフの出力ツリー マップ ビューと混同しています (上記のリンクを参照)。コードをコンパイルしました: valgrind --tool=callgraph ./Program_name と kcachegrind callgrind.out.8389。次の質問があります。

1. main() 関数の上に、「main() の下」と 0x08048bb0 関数が表示されます。これらは何ですか？コンパイラ/OS がプログラム イメージをロードせず、直接 main() にジャンプするためでしょうか。main() を呼び出す前に、プロセスが大量のコードを実行して「実行のためのスペースを空ける」ことを読んだことがあります。これが理由ですか？

2. ツリーの下部には、名前の代わりに 16 進数の関数が多数表示されます。どうしてこれなの？

3. これらの 16 進数は、これらの関数のコード セクションの絶対アドレス (つまり、オフセットではない) または仮想アドレス (またはシンボル) ですか? か否か？

4. -g オプションを使用して、Ubuntu 10.10 でプログラムをコンパイルしました。これらの 16 進数は、「デバッグ情報」がないことと関係がありますか?

5. 「nm program_name」を使用して、何が起こっているのかを把握しようとしましたか? 上記のコール グラフの場合、次の出力が得られます。

1. 「nm」出力に存在するコール グラフからの 16 進アドレスが表示されません。私は混乱しています。

私を助けてください。

さよなら。

ログをプロファイリングすると、Kcachegrind は %of inclusive を 13.92% と表示します。FAQ Q:1に記載されているように、100% に近いはずではありませんか??

これはプロファイルログのスクリーンショットです

KCacheGrind を使用してスクリプトの完全なグラフを取得したいのですが、可能ですか?