apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emery Berger" <em...@cs.utexas.edu>
Subject RE: pools + ap_pfree
Date Sat, 02 Mar 2002 04:19:17 GMT
High-performance was indeed one of my design goals. What tests would you
consider authoritative? I've been using static page loads, driven by a
process on the same machine. This was the best way I found to really
stress pool allocation. I'd be happy to run any other tests you could

-- Emery

Emery Berger
Dept. of Computer Science
The University of Texas at Austin

> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: Friday, March 01, 2002 12:31 AM
> To: Brian Pane
> Cc: Emery Berger; dev@apr.apache.org
> Subject: Re: pools + ap_pfree
> 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
> > a family of interchangeable allocators with different memory
> > 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
> > 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
> > code.  The reason was that the single extra function call
indirection on
> > each apr_palloc() (to support the polymorphic interface) was enough
> > 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

View raw message