Mailinglist Archive: opensuse-programming (32 mails)
| < Previous | Next > |
Re: [suse-programming-e] STL memory pools
- From: Mark Gray <markgray-temp-1100788658@xxxxxxxxxxxx>
- Date: 24 Dec 2004 17:38:13 -0500
- Message-id: <6s7jn7725m.fsf@xxxxxxxxxxxx>
Davi de Castro Reis <davicastro@xxxxxxxxxxxx> writes:
> Hi guys,
>
> Does anyone know how to release all the memory allocated by STL?
> Just let me say why I want to do this. The software I am working on uses
> STL a lot in its first phase. I allocate nearly a 1GB of memory in a lot
> of different STL containers.
What kind of containers and how big are the objects in them?
> In the second phase of the software, I clear() all these container and
> start a custom algorithm that also uses a lot of memory. But the STL
> memory pool is holding quite a lot of memory, and I run out of memory in
> the middle of the algorithm.
What kind of memory allocation do you use in the second phase?
> If I run the two phases of the software in different binaries,
> everything is ok and my algorithm fits in memory. There are no leaks
> that I am aware of in the software (I've already made a lot of valgrind
> checks).
> I do not want to use -D__USE_MALLOC or GLIBCPP_FORCE_NEW=1, since I do
> want the performance of the STL memory pool. I just want to release this
> pool during one of the phases of my software.
The pool is only used for nodes smaller than 128 bytes, and as you
have noticed there is no public/documented/legal way to release memory
from the pool. Therefore if you, for example, are using a list, map,
or set with small nodes your only choice is to write your own custom
allocator. Copying the pool allocator template from:
/usr/include/g++/bits/stl_alloc.h
and adding a member function to deallocate the pool to your version
might be an acceptable solution.
Before you get that far, are you sure that your memory is coming from
the pool? If you are using vectors for instance, you probably are
allocating much larger blocks and totally bypassing the pool. If so,
then you might want to know about the "swap trick" (Item 17 in Scott
Meyers' "Effective STL"):
vector<Stuff> big_vector;
...
... // use big_vector
...
vector<Stuff>().swap(big_vector); // clear big_vector and
// minimize its capacity
because clear() does not decrease the capacity of a vector or
deallocate any memory. Since you are apparently already deep enough
into your problem to have found the "pool" I really hesitate to
suggest this, but I just finished reading "Effective STL" so I
couldn't keep my mouth shut :-)
> Hi guys,
>
> Does anyone know how to release all the memory allocated by STL?
> Just let me say why I want to do this. The software I am working on uses
> STL a lot in its first phase. I allocate nearly a 1GB of memory in a lot
> of different STL containers.
What kind of containers and how big are the objects in them?
> In the second phase of the software, I clear() all these container and
> start a custom algorithm that also uses a lot of memory. But the STL
> memory pool is holding quite a lot of memory, and I run out of memory in
> the middle of the algorithm.
What kind of memory allocation do you use in the second phase?
> If I run the two phases of the software in different binaries,
> everything is ok and my algorithm fits in memory. There are no leaks
> that I am aware of in the software (I've already made a lot of valgrind
> checks).
> I do not want to use -D__USE_MALLOC or GLIBCPP_FORCE_NEW=1, since I do
> want the performance of the STL memory pool. I just want to release this
> pool during one of the phases of my software.
The pool is only used for nodes smaller than 128 bytes, and as you
have noticed there is no public/documented/legal way to release memory
from the pool. Therefore if you, for example, are using a list, map,
or set with small nodes your only choice is to write your own custom
allocator. Copying the pool allocator template from:
/usr/include/g++/bits/stl_alloc.h
and adding a member function to deallocate the pool to your version
might be an acceptable solution.
Before you get that far, are you sure that your memory is coming from
the pool? If you are using vectors for instance, you probably are
allocating much larger blocks and totally bypassing the pool. If so,
then you might want to know about the "swap trick" (Item 17 in Scott
Meyers' "Effective STL"):
vector<Stuff> big_vector;
...
... // use big_vector
...
vector<Stuff>().swap(big_vector); // clear big_vector and
// minimize its capacity
because clear() does not decrease the capacity of a vector or
deallocate any memory. Since you are apparently already deep enough
into your problem to have found the "pool" I really hesitate to
suggest this, but I just finished reading "Effective STL" so I
couldn't keep my mouth shut :-)
| < Previous | Next > |