Good news on the memory issue!

[Paolo Carlini]

Hi everyone...

As often happens, Valgrind is the answer! ;)

Consider insert.cc.

This is a typical picture presented by our check-performance:

type: __gnu_norm::list<int, __gnu_cxx::__mt_alloc<int> >   
15r    8u    7s 25652632mem    9pf

type: __gnu_norm::list<int, __gnu_cxx::__pool_alloc<int> >   
13r    9u    4s  2124296mem   10pf

Shish!!!

Valgrind:

(__mt_alloc)
==29075== malloc/free: in use at exit: 25610938 bytes in 6293 blocks.
==29075== malloc/free: 6298 allocs, 5 frees, 25628674 bytes allocated.

(__pool_alloc)
==29081== malloc/free: in use at exit: 21361711 bytes in 137 blocks.
==29081== malloc/free: 142 allocs, 5 frees, 21379447 bytes allocated.

Indeed, a stupid computation (why I didn't do it before?!?) leads to a
theoretical minimum for this test of:

  10000 iters x 128 inserts x 12 bytes = 15360000 bytes

Therefore, the check-performance numbers for pool_allocator are simply
impossible, way too low! (same for bitmap)

Now, on one hand I feel relieved and happy for mt_allocator, on the
other hand I feel stupid and in need of help for understanding what the
heck are those numbers computed by our check-performance...

Paolo.