You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Pane <bp...@pacbell.net> on 2001/12/02 09:46:31 UTC

prep_walk_cache and pool userdata performance issues

prep_walk_cache(), used to initialize a cache within
(directory|file|location)_walk, is one of the most
time-consuming non-syscall functions in 2.0 at present.

60% of prep_walk_cache()'s run time is spent in
apr_pool_userdata_get() and apr_pool_userdata_setn().

We've tuned the hash table code within these userdata
functions pretty well, but they still require one scan
through a string (to compute the length and hash value)
and at least one memcmp call.  And because all the keys
being used for the walk caches have a "namespace::"
prefix to guarantee uniqueness, we end up doing these
scans on relatively long strings.

I'd really like to switch to some faster mechanism for
storing extra data in the request rec--something with
semantics similar to the pool userdata API, but without
the need to do any extra string comparisons during
request processing.

The easiest solution I've come up with so far is to
introduce a variant of apr_hash_t in which:
  * All keys have to be pointers to global objects
  * The pointer value itself, not the value of the object
    that it references, is used as the key. Thus all
    hash computation and comparison operations can be
    done on pointers rather than the large strings or
    structs that to which they point.

E.g.,

  extern int dir_walk_cache_key;  /* these don't need to be ints */
  extern int file_walk_cache_key; /* any data type will work     */
 
  hash_set(r->extra_data, &dir_walk_cache_key, value);
  ...
  cache = hash_get(r->extra_data, &dir_walk_cache_key);

The basic idea is to use the addresses of global objects as keys,
since these addresses are guaranteed to be unique server-wide.

Comments?

Thanks,
--Brian