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.
If broad locations are listed _first_, followed by very specific (file entity)
locations, then the usual subreq/redirect will have a substantial match, and only
fill in the 'little bits' at the end.
I've also added peek-at-parent/peek-at-previous to help the cache along. This
becomes _absolutely_ critical in the directory_walk-for-dirent-subrequest code
path since we are absolutely in a jam without the prior optimizations we just
ripped from the subrequest code. But it goes ONE STEP FURTHER, since even the
directory entries as subrequests pick right back up from where the parent request
left off :)
Obviously, all of these optimizations are ment to be applied to proxy_walk and
file_walk (almost exact ports, feel free to beat me to these as soon as the final
location_walk patch is submitted) and, with more effort, directory_walk :)
Bill
