Thanks for the pointer; I'll see if I can apply the 'pre-merging'
concept on top of Will's version of directory_walk. In the meantime,
I think I've figured out how to generalize the idea to cover pre-merging
of all non-regular-expression-based directories. Thanks to the
sorting done by ap_core_reorder_directories, and directory_walk's
corresponding pattern of handling all the non-regex directory matches
before any of the regex ones, it's possible to precompute the merged
config vectors for all the non-regex directories as a final post-config
step before handling any requests. E.g., if a server has <Directory>
blocks for '/' and '/foo' and '/foo/bar', it's guaranteed that any request
matching '/foo/bar' will have matched '/' and '/foo' also, so we can
'pre-inherit' the configs for '/' and '/foo' into the config vector for
'/foo/bar' at startup rather than doing the merge repeatedly on each
request. I prototyped this algorithm for the current directory_walk,
and it seems to work properly, but I haven't done extensive testing.
--Brian
[EMAIL PROTECTED] wrote:
>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
>-------------------------------------------------------------------------------
>
>
