apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: [PATCH] optimization for hash tables and pool userdata
Date Wed, 21 Nov 2001 22:58:12 GMT
Mladen Turk wrote:

[...]

>How about to add here something like:
>(in apr_hash.h add #define APR_HASH_KEY_UCASE     (-2)
>
>+    else if (klen == APR_HASH_KEY_UCASE) {
>+        for (p = key; *p; p++) {
>+            hash = hash * 33 + apr_tolower(*p);
>+        }
>+        klen = p - (const unsigned char *)key;
>+    }
>
>that will give you the case insensitive hash table
>

I like this idea, with one modification: I think the
case-insensitive-string-key support should be an attribute
of the hash table that's set when the table is created,
rather than a parameter passed to apr_table_(get|set).
If it's passed on each get/set request, it's possible
for the table to get into a corrupted state.  For
example, if somebody does this:
  apr_hash_set(t, "Key", APR_HASH_KEY_STRING, value1);
  apr_hash_set(t, "Key", APR_HASH_KEY_UCASE, value2);
then apr_hash_get(t, "Key", ...) will return either value1
or value2, depending on whether it's called with
APR_HASH_KEY_STRING_UCASE or not.  That will really
confuse people.

So I'd prefer to do:
  apr_hash_string_make(apr_pool_t *p, int is_case_sensitive)

which would create a hash table optimized for string keys.

There's actually a very good reason to do something like
this: the add_any_filter() function in Apache is slow because
it has to make lowercase copies of strings before passing
them to apr_hash_get().  Having a specialization of apr_hash_t
will support for case-insensitive string keys would improve
the performance.  I'll post a patch for this sometime soon.

--Brian




Mime
View raw message