Gprof 结果:什么是"alloc_mmap"?
Gprof results: what is "alloc_mmap"?
我的程序短期运行的结果如下:
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没有看到
gprof有更多的问题。如果你在linux上,你可以尝试像Zoom这样的分析器。它对挂钟时间进行采样,所以它对I/O不是盲目的。它还提供了按行/指令的时间使用百分比,而不仅仅是按函数,因此它将精确地指出代码中的行,如果您可以改进/删除它们,它们将为您提供最大的加速。(通常是函数调用。"自我时间"很少是相关的,除非在繁重的数学或紧凑的CPU循环中,无论如何它都无关紧要。变焦会发现的)
我所依赖的方法是:
也许您的内存分配器正在使用mmap进行大的分配。您应该首先确认这一点(在alloc_mmap中gdb断点应该可以工作),然后可能使用mallopt增加阈值。
相关文章:
- 如何将PERF_AMPLE_READ与mmap一起使用
- 从结构寻址时,MMAP变量的行为很奇怪
- 子进程更新共享 mmap 内存,但父进程没有更改
- mmap 中的长度是字节数还是页数?
- Linux non-persistent backing store for mmap()
- 在 mmap'ed 区域上使用 memcpy 崩溃,for 循环不会
- 将 mmap 内存用于开销非常低的循环缓冲区
- 在函数中使用 mmap()
- 通过 mmap-ed 共享内存传递可变长度 C 字符串
- 组件对象模型 (COM):IMalloc::Alloc 在哪里分配内存?
- 在C++中打开的带有"fopen"的mmap文件
- 获取错误:在抛出"std::bad::alloc"的实例后终止调用 what(): std::bad_alloc
- mmap with /dev/input/event*
- MMAP仅适用于小文件
- 从shm_open() mmap()更改对共享内存的可见性
- CGAL:Hausdorff距离不良Alloc
- 使用MMAP与FSTREAM或FOPEN访问二进制文件
- 读取文件由c 中的mmap()的浮点数组成
- 使用 mmap 映射文件中的不同段
- C++ mmap 到"fast" 与 gzip 文件的读取耦合