Re: cvs commit: httpd-2.0/server core.c request.c

["William A. Rowe, Jr." <wr...@covalent.net>]

> brianp      01/12/31 00:18:32
> 
>   Modified:    include  http_core.h
>                server   core.c request.c
>   Log:
>   Performance fix for prep_walk_cache():
>   
>   Moved the directory/location/file-walk caches from the
>   request's pool userdata hash table to the core_request_config
>   struct.
>   
>   This change removes about 60% of the processing time from
>   prep_walk_cache().

Brian... this is a very cool patch...

>   +typedef enum {
>   +    AP_WALK_DIRECTORY,
>   +    AP_WALK_LOCATION,
>   +    AP_WALK_FILE,
>   +    AP_NUM_WALK_CACHES
>   +} ap_walk_cache_type;
>   +
>    typedef struct {
>        /* bucket brigade used by getline for look-ahead and 
>         * ap_get_client_block for holding left-over request body */
>        struct apr_bucket_brigade *bb;
>   +
>   +    /* a place to hold per-request working data for
>   +     * ap_directory_walk, ap_location_walk, and ap_file_walk */
>   +    void *walk_cache[AP_NUM_WALK_CACHES];
>    } core_request_config;

However, can we find a way to make AP_NUM_WALK_CACHES a bit more flexible?

See, for example, mod_proxy.  We are doing the same bit there.  Would you
mind extending your patch to allow registration [at startup] of other
cache members?  This could be used for walk caches, or for other sorts of
per-request cached data that currently resides in notes (and should reside
in userdata, until you pointed out how slow that solution really is.)

In any case, nice work :)

Bill

Re: cvs commit: httpd-2.0/server core.c request.c

[Brian Pane <bp...@pacbell.net>]

William A. Rowe, Jr. wrote:
...

>However, can we find a way to make AP_NUM_WALK_CACHES a bit more flexible?
>
>See, for example, mod_proxy.  We are doing the same bit there.  Would you
>mind extending your patch to allow registration [at startup] of other
>cache members?  This could be used for walk caches, or for other sorts of
>per-request cached data that currently resides in notes (and should reside
>in userdata, until you pointed out how slow that solution really is.)
>

I like the registration idea.  I'll work out an API for
it sometime this week.

--Brian