How the standard stl allocator work
thari...@gmail.com
Is the standard stl allocator in gcc is bettor (in performance) than
malloc or is it same as malloc?
I'm going to implement an object pooling mechanism to reduce the
number of memory allocations and deallocations performed.
It seems pointless to use stl containers (such as std::list) to
implement such a mechanism if they start doing memory allocations and
deallocations for every operation I perform on them
TIA,
Tharinda
Alf P. Steinbach
> Hi,
> Is the standard stl allocator in gcc is bettor (in performance) than
> malloc or is it same as malloc?
Just check it if you're interested, but I don't think you need that information.
> I'm going to implement an object pooling mechanism to reduce the
> number of memory allocations and deallocations performed.
Object pooling, as in Java, has the problem of designing objects for zombie
(unusable) states.
Two better approaches:
* Check out the Loki small object allocator.
* Use e.g. boost::shared_ptr to shared instances of an object.
Cheers & hth.,
- Alf
Kai-Uwe Bux
> Hi,
> Is the standard stl allocator in gcc is bettor (in performance) than
> malloc or is it same as malloc?
The standard allocator is based on new/delete. More precisely, allocate()
uses ::operator new(size_t) and deallocate uses ::operator delete(void*).
I do not know whether gcc translates new/delete into malloc/free or whether
it uses some other scheme.
> I'm going to implement an object pooling mechanism to reduce the
> number of memory allocations and deallocations performed.
>
> It seems pointless to use stl containers (such as std::list) to
> implement such a mechanism if they start doing memory allocations and
> deallocations for every operation I perform on them
I don't exactly understand what you are aiming for. The usual way is to
implement a pooling allocator (or some other custom allocator that
implements your memory management scheme) and use that allocator for the
containers.
Best
Kai-Uwe Bux
thari...@gmail.com
On Feb 26, 10:08 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> I don't exactly understand what you are aiming for. The usual way is to
> implement a pooling allocator (or some other custom allocator that
> implements your memory management scheme) and use that allocator for the
> containers.
We knew that creating destroying objects frequently is very in-
efficient. So we have a template based object pooling mechanism in
some processes and when I look into that code it seems that it was
written based on a std::list. So my concern was is it worthless to
write such a pooling mechanism to reduce memory allocations if we are
inserting and removing list elements for every operation (in which it
is indirectly doing the same thing while doing the list operations)?
gob...@googlemail.com
I think you might need Boost Pool library.
Gob00st