httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: cvs commit: httpd-2.0/server core.c
Date Sun, 28 Oct 2001 00:41:04 GMT
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.


View raw message