Gprofの結果：「alloc_mmap」とは何ですか？次のように私のプログラムの短期のため

Question

私の結果は以下のとおりです。

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」を識別することができますか？

Answer 1

プログラムの速度を向上させるためにできることを確認したいと思っているからです。
そうでない場合は、これを忘れてください。

gprofの出力では、2番目の列であるの累積秒数はです。そのルーチンに時間がかからないようにすることができれば、合計時間が短縮されるためです。

gprofの問題の1つは、I/Oのようなブロック時間を無視することです。 あなたのプログラムはalloc_mmap（直接的または間接的）を使用しているので、ファイルをメモリにマッピングしているので、I/Oを実行していることが少なくありません。 gprofに表示されません。

さらにproblems with gprofがあります。 Linuxであれば、Zoomのようなプロファイラを試すことができます。 これは壁時計の時刻にサンプリングするため、I/Oには盲目的ではありません。 これはまた、関数だけでなく、行/命令による使用時間のパーセンテージを与えるので、コード内の行を特定します。その行を改善/削除すれば、最も高速化します。 は、（通常、これらは、「セルフタイム」は重い数学やタイトなCPUループを除いてめったに関連している。関数呼び出しであり、それはとにかく問題ではありません。ズームがそれを発見します。）

私はis thisに依存している方法。

Answer 2

おそらく、あなたのメモリアロケータは、大きな割り当てにmmapを使用しています。最初にこれを確認して（alloc_mmapのgdbブレークポイントが機能するはずです）、おそらくmalloptでしきい値を上げてください。