--- [EMAIL PROTECTED] wrote: > Joe Wilson <[EMAIL PROTECTED]> wrote: > > Is this memory pooling going to be compile-time optional? > > > > I find that library-specific memory pools are awkward because each > > library tends to have its own schemes that don't play well with each > > other. If you use pools, then that limits the effectiveness of Hoard > > or Boehm GC in a big application. > > There are no current plans to make this optional, since to do > so would instantly double the number of configurations I need > to support.
Keeping malloc/free around as a compile-time option might be worth considering if only to be able to debug with Valgrind at the individual allocation level. Trying to debug programs using memory pools, such as the C++ standard template library can be challenging. Some STL implementations offer a malloc/free allocator as a debug alternative. > We have no plans to go to mmap or sbrk for memory. All of the > memory SQLite will manage will come from either a static array > (mem3.c) or from a few large mallocs (mem1.c and mem2.c). I > fail to see how this could adversely effect other libraries > within the same program. It just means that SQLite calls > malloc less often. When an allocator has an entire program's memory to deal with it might be able to optimize its allocations - either for space or speed. For example: http://www.hoard.org/ "...false sharing in your application: threads on different CPUs can end up with memory in the same cache line, or chunk of memory. Accessing these falsely-shared cache lines is hundreds of times slower than accessing unshared cache lines." __________________________________________________ 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] -----------------------------------------------------------------------------
