gm300の日記: vif HL_Read => mmap
日記 by
gm300
read() から mmap に切り替えてさらに一行毎の vector<vline_t>::push_back から list<char *>で一度集めてから vector::reserve -> copy に書き直す。同じく 255Mbyte の最大データで
HL_Map 2.14 sec
HL_Read 6.91 sec
Valgrind を使って新しいコードと古いコードを比較して
- strchr より memchr の方が 20-30% 効率的らしい。
- memcheck は mmap で確保された領域をうまく認識できていない。leak check, malloc/free 量に反映されていない。
領域を連続的に確保できる可能性が増えたことで、見た目のメモリの消費量の減ったような感じがするがこちらの定量的な分析はまだ。
今のところの指標は、
1. FIVA で swap を起さない。dell で mozilla の画面がすぐに出る。
2. ps uxa => 実感とは違う。少なすぎる。
3. valgrind massif => 増(減)は実感に近い。もっと累積的になっているような感じがする。
4. valgrind memcheck+leakcheck => malloc の回数、segment の数は参考になるかも。最終的な leak 量は参考にならない。
さらに昔 grep 2.[23] が遅い理由は mmap にあるとしたあたりを調べ直す必要がある。grep も 2.4 からは mmap は option になったので遅かったのは事実だが、何か条件があるはず。
HL_Map 2.14 sec
HL_Read 6.91 sec
Valgrind を使って新しいコードと古いコードを比較して
- strchr より memchr の方が 20-30% 効率的らしい。
- memcheck は mmap で確保された領域をうまく認識できていない。leak check, malloc/free 量に反映されていない。
領域を連続的に確保できる可能性が増えたことで、見た目のメモリの消費量の減ったような感じがするがこちらの定量的な分析はまだ。
今のところの指標は、
1. FIVA で swap を起さない。dell で mozilla の画面がすぐに出る。
2. ps uxa => 実感とは違う。少なすぎる。
3. valgrind massif => 増(減)は実感に近い。もっと累積的になっているような感じがする。
4. valgrind memcheck+leakcheck => malloc の回数、segment の数は参考になるかも。最終的な leak 量は参考にならない。
さらに昔 grep 2.[23] が遅い理由は mmap にあるとしたあたりを調べ直す必要がある。grep も 2.4 からは mmap は option になったので遅かったのは事実だが、何か条件があるはず。
vif HL_Read => mmap More ログイン