问题标签 [kcachegrind]

使用两者分析一些 C++ 数字运算代码，gprof并kcachegrind为对执行时间贡献最大的函数（50-80% 取决于输入）给出相似的结果，但对于 10-30% 之间的函数，这两个工具给出不同的结果。这是否意味着其中之一不可靠？你会在这里做什么？

我试图了解在使用不同选项运行时程序的性能如何变化——我想解释一下 1.8 的因数。我一直在使用 [valgrind] 的callgrind工具进行分析，并使用kcachegrind来可视化结果。但我真的很想看看差异。我找到了该cg_diff程序，但它不适用于 callgrind 配置文件，只能用于 cachegrind 配置文件，这些配置文件对我来说太贵了，无法收集。 有人知道用于可视化两个配置文件之间差异的工具吗？

Kcachegrind 将默认使用默认的一个 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; kcache 用kcachegrind和研磨qcachegrind-0.7。

这是应用程序的完整调用图。do_J 的所有路径都通过调度程序，这很好（do_1 被隐藏得太快了，但它真的在这里，只是留给 do_2）

让我们重点do_1看看，谁叫它（这张图是不正确的）：

这很奇怪，我认为，只有first2和outer2调用do_1但不是全部。

这是 callgrind/kcachegrind 的限制吗？如何获得带有权重的准确调用图（与每个函数的运行时间成正比，无论有无子函数）？

在此处输入链接描述

嗨，我正在使用 Kcachegrind 分析我的 C 代码。但我对调用图的输出树图视图感到困惑（参见上面提到的链接）。我已经编译了代码：valgrind --tool=callgraph ./Program_name，然后是 kcachegrind callgrind.out.8389。我有以下问题：

1. 在 main() 函数上方，您将看到“main() 下方”和 0x08048bb0 函数。这些是什么？是不是因为编译器/OS没有加载程序镜像直接跳转到main()。我读到过，在调用 main() 之前，一个进程会执行大量代码以“清理执行空间”。这是原因吗？

2. 在树的下半部分，你还会看到很多使用十六进制数字而不是名称的函数。为什么是这样？

3. 这些十六进制数字是这些函数代码段的绝对地址（即不是偏移）还是虚拟地址（或符号）？或不？

4. 我已经使用 -g 选项在 Ubuntu 10.10 中编译了我的程序。这些十六进制数字与“调试信息”的缺失有关吗？

5. 我试图使用“nm program_name”来弄清楚发生了什么？对于上面附加的调用图，我有以下输出：

1. 我没有看到“nm”输出中存在的调用图中的十六进制地址。我很困惑。

请帮我。

再见。

在分析日志时，Kcachegrind 显示 %of inclusive 为 13.92%。如常见问题解答 Q:1中所述，它不应​​该接近 100%吗？

这是配置文件日志的屏幕截图

我想使用 KCacheGrind 获得我的脚本的完整图表，这可能吗？