Hi Richard, This might be worth a read. This paper discusses limitations of custom memory allocators:
Reconsidering Custom Memory Allocation http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf This post by Emery Berger outlines the problems with Apache Portable Runtime (APR) memory pools specifically: http://apache.slashdot.org/comments.pl?sid=120623&threshold=1&commentsort=0&mode=thread&cid=10160124 Emery Berger's Hoard memory allocator is widely used in multi-threaded programs to improve concurrency. I've used it and the speedups are quite remarkable. In one case, a multi-threaded server throughput was 4X faster on a 8 CPU box - just by changing the malloc implementation to Hoard. Mind you, programs with coarse-grained locks will not see that sort of performance increase. As far as general compactness of memory allocation goes, I've had great success with Doug Lea's malloc implementation. Highly recommended. http://gee.cs.oswego.edu/dl/html/malloc.html http://gee.cs.oswego.edu/pub/misc/malloc.c http://gee.cs.oswego.edu/pub/misc/malloc.h http://g.oswego.edu/ --- [EMAIL PROTECTED] wrote: > We are actively working on the memory management problem in a > fork of the source tree. See > > http://www.sqlite.org/mpool/fossil > > The focus of our current research is in reducing memory fragmentation, > but this is very much related to limiting memory usage. Assuming we > achieve good results, the experimental fork will be folded back into > the CVS tree at some point. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
