This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Good news on the memory issue!
- From: Paolo Carlini <pcarlini at suse dot de>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, Stefan Olsson <stefan at xapa dot se>
- Date: Sat, 27 Mar 2004 02:00:21 +0100
- Subject: Good news on the memory issue!
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.