Gprof 结果：啥是“alloc_mmap”？

Posted 2023-03-06

【中文标题】Gprof 结果：啥是“alloc_mmap”？

【英文标题】：Gprof results: what is "alloc_mmap"?Gprof 结果：什么是“alloc_mmap”？

【发布时间】：2011-10-24 02:34:43

【问题描述】：

我的程序的短期运行结果如下：

 67.93      3.24     3.24                             grid::rKfour(int, int)
  9.43      3.69     0.45                             alloc_mmap
  5.03      3.93     0.24    30001     0.01     0.01  grid::timeStep()
  3.04      4.08     0.15 42007105     0.00     0.00  linkers::linkers(linkers const&)
  2.94      4.22     0.14  6360900     0.00     0.00  particle::fulldistance(particle&)
  2.73      4.35     0.13                             blas_thread_server
...

ldd 的输出是

linux-vdso.so.1 =>  (0x00007fffe2bea000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007eff34595000)
    libboost_filesystem.so.1.46.1 => /usr/lib/libboost_filesystem.so.1.46.1 (0x00007eff34377000)
    libboost_system.so.1.46.1 => /usr/lib/libboost_system.so.1.46.1 (0x00007eff34172000)
    libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007eff33f16000)
    libglut.so.3 => /usr/lib/libglut.so.3 (0x00007eff33cd0000)
    libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007eff33a62000)
    libGLEW.so.1.5 => /usr/lib/libGLEW.so.1.5 (0x00007eff3380c000)
    libboost_thread.so.1.46.1 => /usr/lib/libboost_thread.so.1.46.1 (0x00007eff335f3000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007eff332eb000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007eff33067000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eff32e51000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff32ab1000)
    /lib64/ld-linux-x86-64.so.2 (0x00007eff347c4000)
    libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007eff3288d000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007eff32555000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007eff32341000)
    libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007eff3213e000)
    libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007eff31f38000)
    libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007eff31d31000)
    libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007eff31b26000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007eff31922000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007eff31705000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007eff314fd000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007eff312f9000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007eff310f3000)

任何人都可以识别“alloc_mmap”吗？

【问题讨论】：

ldd your-binary 的输出是什么？

所以我在我的系统上找不到它，但我相信如果你用nm 遍历这些库，其中一个应该定义一个名为alloc_mmap 的符号。跨度>

这可能是您的内存分配器（malloc、new 等）下面的一个函数，它通过mmap...获取内存...

另外，另一种方法是在 gdb 中运行应用程序，在 alloc_mmap 中设置断点，然后查看回溯。

查看 gprof 输出中的调用图，这将为您提供有关此函数的位置以及调用者的线索。

【参考方案1】：

我假设您之所以这么问，是因为您想看看可以做些什么来提高程序的速度。 如果没有，请忘记这个。

在 gprof 输出中，重要的数字是第二列，累积秒数，因为如果可以使该例程不花费时间，那么这就是您的总时间将减少的量。

gprof 的一个问题是它忽略了像 I/O 这样的阻塞时间。 由于您的程序正在使用alloc_mmap（直接或间接）它正在将文件映射到内存，因此它正在执行I/O，这通常是不小的成本。 gprof 没有看到它。

还有更多problems with gprof。 如果您使用的是 linux，则可以尝试使用像 Zoom 这样的分析器。 它在挂钟时间进行采样，因此它不会对 I/O 视而不见。 它还按行/指令为您提供时间使用百分比，而不仅仅是按功能，因此它将查明代码中的行，如果您可以改进/删除它们，将为您提供最大的加速。 （通常这些是函数调用。除了繁重的数学运算或紧凑的 CPU 循环之外，“自用时间”很少相关，无论如何都没关系。Zoom 会发现它。）

我所依赖的方法is this。

【参考方案2】：

也许您的内存分配器正在使用 mmap 进行大量分配。您应该首先确认这一点（alloc_mmap 中的 gdb 断点应该可以工作）并可能使用mallopt 增加阈值。