apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: apr-2 pool status [Was: Poor performance with new apr_pool]
Date Thu, 02 Apr 2009 14:10:20 GMT
Mladen Turk wrote:
> So, it's been proven that the new apr pool
> doesn't perform well except on some obscure platforms
> with third-party libraries.
> 

Just did some more profiling on the new apr-pool code
inside httpd. I've simply
#undef malloc
#undef calloc
and add size and number of call counters
(some memory profiler would be better, but
  this one is good enough for the subject)

The plain httpd -k start of httpd trunk
gives the following results in child_init hook

New apr pool:
APR_POOL STATS -- child init
     malloc calls: 14819
     free calls  : 7451
     malloc size : 1327972
     free size   : 784919
     pool create : 148
     pool clear  : 3
     pool destroy: 83
     pool size   : 4172
     palloc calls: 14642
     palloc size : 656700

1.4 apr pool:
APR_POOL STATS -- child init
     malloc calls: 129
     free calls  : 0
     malloc size : 1101928
     pool create : 148
     pool clear  : 3
     pool destroy: 83
     sizeof(pool): 64
     palloc calls: 14640
     palloc size : 698440 - aligned

1.4 apr pool with MIN_ALLOC == 2048
APR_POOL STATS -- child init
     malloc calls: 211
     free calls  : 0
     malloc size : 540776
     free size   : 0
     pool create : 148
     pool clear  : 3
     pool destroy: 83
     pool size   : 64
     palloc calls: 14640
     palloc size : 698440

This means that average apr_palloc/calloc is 45 bytes
(48 bytes in old apr because of alignment) just to
startup the server. If you involve the request processing
think the average size will be even lower.

So I doubt in any numbers showing the simple
pointer math is slower then a function call
even with tcmalloc, but ... ;)

Finally, what does those numbers mean?
Both implementations suck :)
For an total requested size of 640K we ended
with allocated 1M from the system using 1.4
apr pool.
Interestingly the new implementation is much better
regarding that. After settling it consumes less
memory, but it suffers from peek usage, where
the usage goes much higher until pool get cleared.

However if I change the MIN_ALLOC to 2048 and
adjust the BOUNDARY_INDEX to 10, the total
memory usage lowers to 512K.

Regards
-- 
^(TM)

Mime
View raw message