William A. Rowe, Jr. wrote:
>From: "Brian Pane" <[EMAIL PROTECTED]>
>Sent: Tuesday, September 04, 2001 6:20 PM
>
>
>>William A. Rowe, Jr. wrote:
>>
>>>We are on the same page :) FWIW, I've made a few comments around your patch,
>>>and am reviewing it in more detail. I'll have my comments by the end of the
>>>week (I'm all over creation this week trying to get things done.)
>>>
>>Interestingly, I'm not seeing a measurable speedup from the patch in
>>benchmark testing (which is surprising because Quantify data has shown
>>dir_merge functions to be a major consumer of CPU time). It may not be
>>worth considering the patch further.
>>
>
>May I first finish the work, then, on allowing location_walk to cache preserve
>the individual 'merge steps' on it's way to creating the end-result?
>
>The patch I will commit tommorow aftn extends location_walk's cache in absolute
>contradiction to my earlier, proposed optimization :) It will save each unit
>of work, so that any subreq/redirect will use each sequential cache match, until
>that subreq/redirect misses a step that was cached, or hits a location that wasn't
>originally cached. Then it starts merging again, from however far it got, until
>the end of the locations list.
>
This sounds good. If the static-cache concept survives, I can just apply it
against the new location_walk.
Meanwhile, I'm looking at profile data that explains why I couldn't measure
the speedup: while dir_merge operations are one of the more time-consuming
parts of Apache, they only account for around 1% of the total CPU usage.
As other things get optimized, and the dir_merge functions represent a
bigger percentage of the remaining CPU time, the effect of the pre-merge
may be more noticeable.
--Brian
