apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: Poor performance with new apr_pool
Date Thu, 26 Mar 2009 17:14:00 GMT
Joe Orton wrote:
> 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.
>   

Nah, we're not testing that hypothesis. We're testing the hypothesis
that "most recent C libraries have a modern malloc implementation",
which is clearly false. And we're ignoring not-so-recent C libraries,
like Mladen't RHEL-4 example.

If someone is certain that she can do better than pools, she can still
write her own allocator and use that.

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

Subversion's "make check" is strongly I/O-bound, so timings would
probably not show a thing. We don't have any load tests, I'm afraid.

-- Brane


Mime
View raw message