On Thu, Feb 28, 2002 at 10:20:15PM -0800, Brian Pane wrote: > We saw this with the SMS allocators last year. SMS had a great design: > a family of interchangeable allocators with different memory management > implementations, and an single, abstract interface to all of them so that > one could easily plug in the right type of allocator for a given app. > The problem was that the httpd got measurably slower when the SMS version > of the simple pool allocator was used in place of the original apr_pool > code. The reason was that the single extra function call indirection on > each apr_palloc() (to support the polymorphic interface) was enough to > negatively impact the performance.
Yup, and on a tangential note, I'm hoping that this new bucket freelist API won't have this problem that SMS had. But, in the bucket case, we are currently using malloc()/free(), so introducing any freelist should be an improvement. *crosses fingers* apr_pfree is a good idea in concept, but we have to measure the performance impact carefully. Perhaps, this is 2.1 material? Certainly not 2.0 and definitely not 1.3. -- justin
