apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Poor performance with new apr_pool
Date Thu, 26 Mar 2009 17:06: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.

That's all true, but the pool's purpose is not to be malloc replacement.
This new concept remembers the allocated chunks of data,
so it's pretty unreliable regarding performance predictability.
Smaller chunks cause larger memory usage, because you have
to remember many tiny pointers. With things like concatenating
8 char string, you actually have doubled the memory usage
(8+ bytes for data depending on the malloc implementation +
  4(8) bytes for storing this pointer)
So the memory doesn't depend on the allocated size only,
but on the allocated quantity as well.

That's why I think this new concept doesn't fit in the
apr_pool usage entirely. Well at least for the string, table and
hash operations which are hugely used across httpd.

However, for non string operations like managing
system objects, it probably makes no difference.

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



View raw message