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

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-27 06:01:34

"E. Gladyshev" <egladysh_at_[hidden]> writes:

> --- 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.

He would not.  He would pick an off-the-shelf memory manager such as
dlmalloc that has been shown to perform well in a wide variety of
applications.

> 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.

Hypothetical or real?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com