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 recommend.
Thanks, -- Emery -- Emery Berger Dept. of Computer Science The University of Texas at Austin www.cs.utexas.edu/users/emery > -----Original Message----- > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] > Sent: Friday, March 01, 2002 12:31 AM > To: Brian Pane > Cc: Emery Berger; [email protected] > 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 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
