apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: pools + ap_pfree
Date Fri, 01 Mar 2002 06:30:42 GMT
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


Mime
View raw message