Re: [boost] Re: what happened to allocators in boost?

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-26 22:08:59

--- David Abrahams <dave_at_[hidden]> wrote:
> "E. Gladyshev" <egladysh_at_[hidden]> writes:
> 
> > --- David Abrahams <dave_at_[hidden]> wrote:

> > Yes, I am sure. I shipped one of my libraries to a guy who
> > works on various DSP chips.  The native memory allocator
> > on one of the DSP was very slow (some specific issues with
> > how the DSP addresses the memory, I don't remember the details).
> >
> > This guy had to add his own new/delete operator to some of
> > my internal classes to get about 10 times performance improvement.
> 
> None of that indicates that he couldn't have replaced the native
> allocator with a fast general-purpose allocator.
> 
> > No, I really don't think that there is a hope for general purpose
> > allocators.
> 
> Why not?

Sure he could have replaced the system allocator (I actually suggested it too)
but why would he want to do it? 
The standard system allocator worked just fine for the rest of his program.
Why would he want to implement a full blown memory manager.

The problem was that my library had couple classes that 
get allocated/deleted very often it was the biggest performance hit.
He just overloaded the new/delete in these classes and built 
a very simple fixed-size memory manager in a separate heap
just for that.

In fact a program might require different allocation
strategies depending on the context.  Replacing the global 
new/delete may not be an option.

Eugene

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com