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

 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”吗?

最佳答案

我想您是在问,因为您想知道可以采取什么措施来提高程序的速度。
如果没有,就算了。

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

gprof的问题之一是它会忽略I / O之类的阻塞时间。
由于您的程序(直接或间接)使用alloc_mmap,因此它正在将文件映射到内存,因此它正在执行I / O,这通常是不小的开销。
gprof没有看到它。

还有更多的problems with gprof
如果您使用的是Linux,则可以尝试使用Zoom之类的探查器。
它在墙上时钟时间采样,因此它对I / O不会造成影响。
它还可以按行/指令(而不只是按功能)为您提供百分比的时间使用率,因此,它可以查明代码中的行,如果可以改进/删除它们,则可以最大程度地提高速度。
(通常这些是函数调用。“自定义时间”很少涉及,除非在数学运算繁重或CPU循环紧张的情况下,而且这无关紧要。Zoom会发现它。)

我依靠的方法is this

关于c++ - Gprof结果: “alloc_mmap”是什么?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/7870851/

10-14 07:01