Brian,
see my commit to core/request.c ... I've dropped in the new directory_walk
code.
I'd like us to optimize it for things we _know_ (e.g., it's given as a
<Directory > so skip the stat, unless FollowSymLinks isn't set, and assume
for the remainder of the request that it _is_ a directory) and then introduce
your optimizations. Hopefully both branches in the same source help us keep
running while we keep developing. Focus on the second directory_walk function
since the first will be deprecated and removed when we've got it right :)
Bill
----- Original Message -----
From: "Brian Pane" <[EMAIL PROTECTED]>
To: "new-httpd" <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 4:03 PM
Subject: directory_walk performance
> 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
>
>
>
