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)
