Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates
 66.187.237.31 as permitted sender)
Date: Thu, 26 Mar 2009 15:24:59 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: Poor performance with new apr_pool
Message-ID: <20090326152459.GA11662@redhat.com>
Mail-Followup-To: dev@apr.apache.org
References: <49CB671F.9040801@apache.org>
 <4239a4320903260549s3679e713u3f314a870e7ad24b@mail.gmail.com>
 <49CB8CF0.10005@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <49CB8CF0.10005@apache.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
> What's the point?

The null hypothesis is: modern malloc implementations do exactly the 
same optimisation work (e.g. maintaining freelists) that we duplicate in 
APR pools.  By avoiding that duplication, and relying on malloc 
optimisation, we might get better/equivalent performance whilst reducing 
the complexity of APR.

So, we're testing that hypothesis.  If it's shown to be false, then, we 
revert back to the old allocator.  That doesn't mean it's not worth 
trying.

Also, I think it would be more useful to benchmark something like 
Subversion's "make check", or an httpd load test.

joe