And thus spake Robert Fendt
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