Gprof結果：什麼是「alloc_mmap」？是

我對我的程序的一個短期結果如下：Gprof結果：什麼是「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」？

來源

2011-10-24 Mikhail

'ldd your-binary'的輸出是什麼？ –

所以我在我的系統上找不到它，但我相信如果你用'nm'遍歷這些庫，其中一個應該定義一個名爲'alloc_mmap'的符號。 –

這可能是你的內存分配器（malloc，new，whatever）之下的一個函數，它通過'mmap'獲取內存... – rlibby

我假設你問，因爲你想看看你可以做些什麼來提高程序的速度。
如果沒有，忘記這一點。

在gprof輸出中，重要的數字是第二列，累計秒數，因爲如果可以使該例程不需要時間，那麼這是您的總時間縮短的量。

gprof的一個問題是它忽略了像I/O那樣的阻塞時間。由於你的程序使用alloc_mmap（直接或間接）它將文件映射到內存，所以它正在做I/O，這往往不是一個小的代價。 gprof沒有看到它。

還有更多problems with gprof。如果你在linux上，你可以試試像Zoom這樣的分析器。它在掛鐘時間進行採樣，所以對I/O不是盲目的。它還爲您提供按線/指令使用百分比的時間百分比，而不僅僅是按功能，因此它會精確定位代碼中的行數，如果您可以改進/移除它們，則會爲您提供最快的加速。（通常這些都是函數調用，除了重數學或者緊密的CPU循環之外，「自我時間」很少相關，無論如何它並不重要，縮放將會發現它。）

我依靠的方法is this。

來源

2011-10-24 13:39:18

也許你的內存分配器正在使用mmap進行大的分配。您應該首先確認這一點（alloc_mmap中的gdb斷點應該可以工作），並且可能會增加mallopt的閾值。

來源

2011-10-24 14:51:23 cdleonard

Gprof結果：什麼是「alloc_mmap」？是

回答

相關問題