Re: [Boost-users] Memory problem using shared_ptr w/ STL-containers, gcc

From: Robert Fendt (robert_at_[hidden])
Date: 2006-10-19 20:19:13

And thus spake Robert Fendt <robert_at_[hidden]>
Fri, 20 Oct 2006 00:31:34 +0200:

> Well, I have to apologise in one respect, the memory definitely gets
> re-used, which is a relief. What remains is the impossibly-large memory
> footprint of >10kb per object, which I have to investigate further. At the
> moment it is such that a list of a little over 5000 (small) POD objects
> eats well over 100MB of memory, and that just can't be right... however I
> will check if this is really caused by the shared_ptr...

Okay, and now the second part of the mystery was revealed. I am almost
too embarrassed to tell... let's just say implementing classes at 3:00 in
the morning is almost never a good idea... there is a time_date member in
the class, and since I have to be able to set the time via an input
string (and because time_date can use streams quite beautifully) there is
of course need for a stringstream...

To make a long story short: PEBKAC. Or "it appeared like a good idea at
the time (i.e., 3:00) to make the conversion stream non-static". IOW:
every object got its own stream, which of course blew the size in memory
totally out of proportion.

Add to that the behaviour of the GCC runtime that even large chunks of
memory are usually *not* released to the system but rather held in a
memory pool for re-allocation, the confusion was perfect. At first glance
the effect was seemingly replicated even in my small test case, but this
was not the case. So this is neither a bug in Boost nor in GCC.

Thank you all,
Robert