Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-08-30 10:45:30


From: Toon Knapen <toon.knapen_at_[hidden]>
> On Friday 30 August 2002 10:01, Rob Stewart wrote:
> > From: Toon Knapen <toon.knapen_at_[hidden]>
> > > On Friday 30 August 2002 09:30, Rob Stewart wrote:
> > > >
> > > > Why isn't the default appropriate? As long as your code
> > > > allocates and destroys its own memory, it's memory allocations
> > > > will not need to interact with those of your callers.
> > >
> > > but you might want to get some memory-space from the application that you
> > > can use to quickly create and destroy temporaries. An allocator would be
> > > a good solution. The application can also provide an interval of
> > > addresses in memory that can be used by this component for doing
> > > placement-new's.
> >
> > I still don't see the point. The library code can allocate and
> > deallocate memory as it sees fit. It can use new/delete,
> > std::allocator<...>, or whatever. As long as the library doesn't
> > allocate memory and hand it off to the caller, or if the memory
> > allocation is managed in an object that defers to the library to
> > release it, there is no problem.
>
> First, every new involves a system call so if you do a lot of new's you're
> better of first allocating a memory pool (only one system call) and using
> placement new to create/destroy many small objects.

This is just fundamental, performance-concious memory
management. It is not the reason the allocator issue was raised.

> The application might not like it that every library is going to allocate its
> own pool, it's better to have one big pool that can be used by all libraries.
> This minimises memory scattering (I'm not sure about the correct english
> term, it's just if you have many small holes in your memory and you are
> allocating new big objects, you're going to lose a lot of memory space ;
> which is important for memory-hungry applications like scientific simulation
> codes)

All of which would have bearing if the library managed a memory
pool. As it turns out, the problem is actually one of potential
recursion into malloc() which a memory pool wouldn't resolve
unless the entire pool could be preallocated.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk