Re: memory efficient STL allocator alternatives?
Eric Meijer ha scritto:
Here is some output of my analysis of a run that computes the data
structure:
min, avg, max elements : 1, 43.8756, 201
So on average some 44 elements, in a range from 1 to 201.
I also checked the vector.capacity(), which gave me this interesting
result:
min, avg, max vector capacity : 1, 63.801, 256
Apparently on average any vector was 20 elements larger at some point
during the computation than at the end, something I hadn't realised. I
verified that the vector implementation does not overallocate.
vector implementations usually don't overallocate on resize() or
reserve() but they usually do so on push_back(). In fact, the gcc
implementation of push_back() adds elements up to capacity(), then
reallocates by doubling the capacity. It's not a coincidence that the
max capacity is exactly 256!
My conclusion so far is that I should find / write a container that
actually releases memory back to the allocator if it shrinks. It
remains to be seen if the actual peak memory usage can be reduced. The
vector's strategy of the gnu libstdc++ appears to be at least very
reluctant to really release memory when it is reduced in size. This
strategy is too wasteful for my particular use case.
Another poster already mentioned the swap-trick to shrink a vector, that is:
std::vector<..>().swap(v);
Notice that C++0x will provide std::vector with a new method called
shrink_to_fit() to perform that task without "tricks".
HTH,
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]