--- 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. 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
