> Bill Stoddard wrote: > > >Subroutine Name Source File Ratio Enter % > >Cycles > >=============== =========== ===== ===== ==== > >====== > >.core_input_filter core.c 3.15 11 > 1.5 3628 > >.ap_rgetline_core protocol.c 3.05 6 > 1.3 3241 > > > > Are these numbers from the latest version of ap_rgetline_core(), with > the optimization to re-use the same temp brigade for the lookahead read? > If so, I'll proceed with the next wave of fixes on that function (using > a persistent brigade) to try to optimize it out of the top 5.
These results are from 1.107 and the optimization went into 1.108. I'll rerun the profile with HEAD and post the results. > > >.get_filter_handle util_filter.c 4.58 2 > 1.1 2705 > >.ap_find_token util.c 4.16 6 > 0.9 2306 > > > > Wow, I've never seen ap_find_token() rank so high in a profile before. > Does your profiling tool show any information on where it's > getting called? ap_set_keepalive calls ap_find_token three times. Ooops, I see I am calling ap_set_keepalive twice (once to many) in mod_cache. I'll correct this. > > >.fix_hostname vhost.c 3.65 1 > 0.7 1626 > > > > fix_hostname() is spending all its time in string processing and > string-to-int > conversions. There's probably an optimization opportunity there. > > >.ap_update_child_status_from_indexes scoreboard.c 17.94 2 > 0.6 1435 > > > > Is the high ratio here just a result of the cost of writing to the > scoreboard > in shared memory? I suspect so. Bill
