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
