Re: Good news on the memory issue!

[Dhruv Matani <dhruvbird at gmx dot net>]

So, now how does one get the correct answer with the test-suite?


On Sat, 2004-03-27 at 06:30, Paolo Carlini wrote:
> 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.
-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html