Good news on the memory issue!
Sat Mar 27 03:32:00 GMT 2004
As often happens, Valgrind is the answer! ;)
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
==29075== malloc/free: in use at exit: 25610938 bytes in 6293 blocks.
==29075== malloc/free: 6298 allocs, 5 frees, 25628674 bytes allocated.
==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...
More information about the Libstdc++