Just a heads up, because I know he's off-list this weekend. Will Rowe has
been looking at some of this stuff recently. He has basically re-worked
directory walk to take advantage of a lot of the stat() calls that have
already been made. Brian, I would suggest sending him e-mail on Monday so
that you can take advantage of his work. He says it's not quite ready for
public consumption yet, but I'm sure he'll send it if there is interest.
BTW, this idea is great, I would love to see a patch, especially if it can
be generalized at all!
Ryan
On Sat, 23 Jun 2001, dean gaudet wrote:
> that sounds good.
>
> it's just like constant-folding :)
>
> can you generalise it any? Alias and mod_userdir can add more constant
> factors in the path.
>
> -dean
>
> On Fri, 22 Jun 2001, Brian Pane wrote:
>
> > More fun with gprof...
> > directory_walk is one of the bigger consumers of user-mode CPU time in
> > the current 2.0 httpd source, due largely to its calls to
> > ap_merge_per_dir_configs.
> >
> > For a typical configuration that has one <Directory> config for '/' and
> > another for
> > the document root path, it looks like all requests for real files will
> > follow the
> > same pattern:
> > * Initialize per_dir_defaults to be the default_lookups for the vhost
> > matching
> > the request
> > * Merge the configs for '/'
> > * Merge the configs for the document root path
> >
> > I.e., the same merge of the / and /document/root configs is happening on
> > every
> > request.
> >
> > Assuming that this configuration style (with a <Directory> block for the
> > document root path) is indeed common, would it be feasible to precompute
> > the merge of the '/' configs with the /document/root configs after
> > initialization
> > to support optimized handling of this case in directory_walk? In the
> > implementation
> > I'm thinking of, the logic in directory_walk would look something like:
> > if (path begins with sconf->ap_document_root) {
> > per_dir_defaults = precomputed merged configs for document root;
> > scan the rest of the path (after the docroot prefix) for
> > possible additional dir matches;
> > }
> > else {
> > use the current algorithm;
> > }
> >
> > Would that sort of optimization make sense, or is it too special-purpose
> > (or too
> > incorrect, even) to be generally useful?
> >
> > Thanks,
> > --Brian
> >
> >
> >
>
>
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
