问题标签 [callgrind]

我对如何解释 QCachegrind 中的“Self”插槽感到困惑。是函数的每次调用成本，还是函数在调用 x 次时的总成本，其中 x 由“被调用”的插槽表示？

（请看下图）

调用一次的函数成本是 0.003 吗？还是我需要将它除以 2（“被调用”插槽）以获得每次调用的函数成本？

我想使用 callgrind 来分析我的程序，但是速度太慢了。我想要做的是使用 kcachegrind 生成一个调用图，其中每个节点显示程序在哪个函数中花费的百分比。你能告诉我我可以安全地禁用哪些功能以获得更好的性能，以便仍然生成此信息吗？

非常感谢！

我的主程序是由 C 编写的。C 代码通过其 C API 调用解释器语言，比如 python。然后解释器语言回调其他 C API。所有的 C 代码都是可调试的，解释器语言的 C 接口也是可调试的。

我发现 callgrind 无法分析解释器语言调用的 C 代码。它的调用树在调用解释器语言的 C 代码处停止。

这是 callgrind 的任何已知限制吗？Oracle Solaris Studio 在此案例中工作。

在此之后，我用 CALLGRIND_xxx_INSTRUMENTATION 宏包装了我的函数。但是，我总是“失忆”。

这是我的程序的简化版本，即使我可以在不使用宏的情况下运行 callgrind，callgrind 仍然会耗尽内存。

要运行它，“valgrind --tool=callgrind --instr-atstart=no ./foo >foo.out”。

我做错什么了吗？请帮忙。谢谢！

我目前正在尝试分析和调试我正在使用的库的性能问题。出于这个原因，我编写了一个简短的C++代码，它将使用该库的一些核心功能并在其上运行一个简单的计时器。

为了更深入地了解，我现在开始使用带有--tool=callgrind选项的 valgrind。我使用kcachegrind. 我以前做过，并且（原则上）知道这是如何工作的。

但是，看到这样的模式，我感到非常惊讶：

在此之后，调用图就停止了，尽管我可以在列表中看到更多的低级函数。

我相信调用图的这种结构可能与使用多处理的库有关，对此我之前没有使用过 valgrind。但是，使用谷歌，我无法找到这个特定函数调用的解释。

有人可以向我解释我在这里看到的内容，以及为什么调用图在这个函数调用中似乎断开了连接吗？

我正在使用卷云机，对我的 C 代码进行分析。我已经安装了 Valgrind。但是我得到的输出--tool=callgrind几乎无法理解，因此我想使用 kcachegrind 工具。但我找不到在 linux 终端/卷云上安装它的链接。

我想测量 c 源代码中每个函数花费的时间，但在 python 中使用 ctypes 运行。有没有办法在 python 执行中使用 valgrind 和 callgrind？

我正在尝试分析一个需要从 sqlite 数据库加载数据的程序。运行程序通常按预期运行，但是当我使用 callgrind 时，打开的数据库是空的（没有表；在数据库中设置的 user_version 返回为 0）。数据库文件在正确的路径中找到，并且似乎已正确打开，但其中没有任何内容。

测试程序（sqlite_test.cpp）：

我创建了一个具有“pragma user_version = 5;”的数据库（“testDB”），并且与可执行文件位于同一文件夹中。可执行文件是使用

输出：

我注意到的另一件事是，它在使用 valgrind (memcheck) 运行时似乎工作正常。只有 callgrind 才会出现问题。valgrind 3.12 和 3.14 都是如此。

更新：显然我应该提到我正在运行它，因为它似乎是问题的根源。我的问题是在单核 ARM 处理器上运行 Yocto 2.2.2 (Morty) 的系统上。如果我在运行 Ubuntu 18.04 的不同系统（即虚拟机）上运行相同的东西，则没有问题。我不确定这些系统之间的哪个差异导致了问题。

查看我的程序运行时 callgrind 的输出，我看到 125% ！！！的周期花费在 _dl_runtime_resolve_xsave'2（显然是动态链接器的一部分）中，而 100% 花费在 main 中。但它也表示，几乎所有在 _dl_runtime_resolve_xsave'2 中花费的时间实际上都花在了内部方法中（self=0%），但 callgrind 没有显示该方法的任何被调用者。此外，看起来 _dl_runtime_resolve_xsave'2 是从我正在分析的程序中的多个位置调用的。

我可以理解，可能会在 main 之外花费一些时间，因为我正在分析的程序正在使用原型模式，并且在加载动态库时正在构建许多对象原型，但这不能接近 25% 的时间特定的运行（因为如果我在没有输入数据的情况下运行，它所花费的时间比我现在正在分析的运行要少几个数量级）。

此外，该程序在程序启动后未使用 dlopen 打开共享对象。一切都应该在开始时加载。

这是 kcachegrind 窗口的屏幕截图：

如何解释对 _dl_runtime_resolve_xsave'2 的调用？我需要担心在这种方法中花费的时间吗？

谢谢您的帮助。

我正在使用 valgrind 的 callgrind 来分析程序，然后使用 kcachegrind 来查看配置文件数据。我已经将 callgrind 的输出文件复制到另一台机器上，并在那里有源代码的副本，但显然源代码的路径信息被烘焙到 callgrind 的格式中。这意味着 kcachegrind 找错地方了：

有没有办法传递相对源代码路径，以便我可以在一台机器上分析程序，然后将分析数据传输到另一台机器并仍然查看源代码？