"E. Gladyshev" <[EMAIL PROTECTED]> writes: > --- David Abrahams <[EMAIL PROTECTED]> wrote: >> "E. Gladyshev" <[EMAIL PROTECTED]> writes: >> >> > --- David Abrahams <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
