httpd-dev mailing list archives

Brian Pane wrote:
> Aaron Bannert wrote:
[...]
>> I agree that in general we probably don't want to go around replacing
>> these things everywhere, but in some cases (like inside a tight loop
>> in a filter that gets called many times during a single request) it may
>> make sense. But that's why we have two ways to allocate memory, right?
>>
>
> The next time I have a chance to look at profiler data (probably in
> the next week), I'll check where the expensive apr_pcalloc calls are
> and post a summary. Most of the obvious calloc->alloc wins from past
> profiling efforts have been fixed already, but the code base has also
> changed a bit since then.
I have some data now:
apr_pcalloc constitutes about 3% of the total non-syscall CPU time
in the httpd. Of the time spent in apr_pcalloc, the distribution
to its callers is:
includes_filter 34.40%
make_array_core 22.48%
alloc_array 15.68%
add_any_filter 6.53%
create_empty_config 4.67%
apr_file_open 2.27%
make_sub_request 2.06%
alloc_socket 2.00%
prep_walk_cache 1.78%
apr_mmap_create 1.78%
merge_dir_configs 1.20%
ap_read_request 1.14%
plus many others that each contribute less than 1%.
Of these, includes_filter and add_any_filter, and
apr_file_open look like good candidates for optimization.
--Brian