问题标签 [kcachegrind]

我第一次尝试使用 Callgrind/Kcachegrind 来分析我的 C++ 应用程序，我注意到需要更多时间的两个函数是：

1. < 循环 1 > (50% 自我) 和
2. do_lookup_x (15% 自我)

现在，根据我的理解，周期 1 与递归调用函数所用时间的估计有关，但我不太清楚我应该如何解释在这里花费的如此长的时间。如果有一些周期，我想看看哪个函数被调用得更频繁，最后占用更多的 CPU 时间。如果我禁用循环检测（视图->循环检测），那么循环 1 会消失，但“自我”时间总计约为 60%，我不确定这是最好的做法。关于 do_lookup_x 我完全一无所知......

你能澄清一下我应该如何解释这些结果吗？

提前致谢。

X 调试将输出作为部分返回，而不仅仅是一个文件。我正在使用 ubuntu 16，不知道为什么突然输出在几个文件中。我遇到的问题是我无法在 Kcachegrind 中打开这些文件，因为输出在单独的文件中有不同的部分。任何人？提前致谢

我想分析python代码的性能，为此我使用了cProfile模块并生成了python文档中提到的.cprof文件。我正在使用pyprof2calltree python 模块将 .cprof 文件打开到KCacheGrind。. 我放了分析结果的截图，它显示名为cycle 5的函数占用了 100.04% 的 CPU 时间。我无法理解这代表什么。它也没有显示此功能的任何源代码。

我valgrind --tool=callgrind ./executable在以下代码生成的可执行文件上运行：

我debug使用以下选项进行构建：-fPIC -fno-strict-aliasing -fexceptions -g -std=c++14. release构建具有以下选项：-fPIC -fno-strict-aliasing -fexceptions -g -O2 -std=c++14.

运行 valgrind 会生成两个转储文件。当在 KCachegrind 中查看这些文件（一个用于调试可执行文件，另一个用于发布可执行文件）时，调试构建是可以理解的，如下所示：

正如预期的那样，该函数XYZ::Count() const被调用了 10001 次。但是，优化的发布版本更难破译，并且根本不清楚该函数被调用了多少次。我知道函数调用可能是inlined. 但是如何确定它实际上已经被内联了呢？发布版本的调用图如下所示：

似乎根本没有任何功能XYZ::Count() const迹象main()。

我的问题是：

(1) 不查看调试/发布版本生成的汇编语言代码，以及使用 KCachegrind，如何计算出特定函数（在这种情况下XYZ::Count() const）被调用了多少次？在上面的发布构建调用图中，该函数甚至没有被调用一次。

(2) 有没有办法理解 KCachegrind 为发布/优化构建提供的调用图和其他细节？我已经查看了https://docs.kde.org/trunk5/en/kdesdk/kcachegrind/kcachegrind.pdf上的 KCachegrind 手册，但我想知道是否有一些有用的技巧/经验法则应该看用于发布版本。

当使用 kcachegrind 或者只是objdump -C -l -d somelib.so我注意到我的共享库中的一些调试信息不​​是最新的，这是由于从构建机器的本地文件系统复制到安装的共享网络文件系统的过程。

工作流程是：

• 构建机器检查源/workspace/build/PROJECT/VERSION/dirs_with_sources
• 在本地构建-g
• 构建后将源复制到/software/PROJECT/VERSION/dirs_with_sources并将构建的共享库复制到/software/PROJECT/VERSION/InstallArea/ARCHITECTURE/lib

当我现在打开共享库时，objdump -C -l -d somelib.so我会看到如下调试符号：

这里的文件名不能只是复制和粘贴，因为我没有在我的用户计算机上安装构建目录并且需要替换/workspace/build为software.

这很烦人，但在运行例如源查找失败的 kcachegrind 时会严重失败。（而且我假设其他旨在帮助我在源代码和构建输出之间导航的调试工具会遇到类似的问题）。

有没有一种通用的方法来处理可重定位文件的调试符号？我认为在发布带有调试符号的库的二进制版本时，这应该始终是一个问题。

编辑：

我用作解决方法并希望避免作为一般解决方案的方法：

• mount /softwareto /workspace/build: (kcachegrind) 用户可能没有创建权限/workspace

• 从源代码重新编译以获得固定的调试信息：这可能需要比用户愿意投资更多的编译时间（可能还有用户磁盘）（这就是我们首先拥有构建机器和网络安装的部分原因）。

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

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

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

我是分析新手。我正在尝试使用 xdebug 分析我的 PHP。

cachegrind 文件已创建，但没有重要内容

我已经设置 xdebug.profiler_enable_trigger = 1 xdebug.profiler_output_name = cachegrind+%p+%H+%R.cg

我用额外的 GET 参数调用我的页面 ?XDEBUG_PROFILE=1 我的 cachegrind 文件已生成但没有重要内容

这是我的输出：

就是这样-我一定缺少一些基本的东西。

我想分析我的 Python 程序以了解它为什么这么慢。我决定使用 Yappi——因为我的程序是多线程的——并使用 KCacheGrind 来显示结果。这是我的做法：

update 方法用于从数据库中获取时间范围在开始和结束之间的数据。

输出文件已正确创建，但是当我启动 KCacheGrind 时，它会打印出很多这样的错误：

我最终得到了这个调用图，其中所有不可识别的函数都聚合为一个，使其变得混乱且完全不相关。有谁知道为什么会这样？

我目前正在使用 Valgrind 在 Linux 系统上对程序进行基准测试。我用 getter 方法遇到了这个奇怪的缓存缺失const int GetID() const，但我无法真正解释它的来源。有谁知道是什么导致了这个问题？我认为这可能是由最后的常量关键字引起的，但它并没有改变。

在读取操作期间，缓存未命中发生在 L1 中。我在代码片段下方添加了一个屏幕截图。

KCachegrind 截图：

更新：

这些是调用该方法的 GameManager 类的const int GetID() const方法。当必须销毁游戏对象或将其返回到特定点时调用它。GameManager 包含所有 GameObjects 的向量，它们是在应用程序启动时创建的，之后该向量根本不会改变。创建后，附加组件调用该GameObject* GetGameObject(int const _gameObjectId)方法一次以检索所有必需的组件。所以我猜游戏对象应该已经在缓存中或者我错过了一点？也许调用是如此强大以至于它在程序开始时比运行时应用程序的其余部分创建更多的缓存未命中？