httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: What to do about tables?
Date Mon, 05 Nov 2001 03:05:17 GMT
On Sun, Nov 04, 2001 at 03:00:43PM -0800, Brian Pane wrote:
>...
> 2. Change the performance-sensitive fields in the httpd's request_rec
>    from apr_table_t (like r->headers_in) to some different data type
>    (e.g., "ap_http_headers_t") that supports O(log(n)) or O(1) get/set
>    operations
>       Pros:
>         * Performance improvement for the httpd
>         * Other code that uses apr_table_t isn't affected
>       Cons:
>         * Lots of changes required to the httpd core and all modules

This is the most optimal approach. You can build a structure that is O(1)
for the common headers (by using tokens for the headers rather than
strings). Other headers can also be heavily optimized through a hash lookup.
I think this custom type would be a wrapper around an apr_hash_t.

> 3. Keep using apr_table_t for the fields in request_rec, and redesign
>    the internals of apr_table_t to support O(log(n)) access
>      Pros:
>        * Performance improvement for the httpd
>        * Almost no impact on code that uses APR
>      Cons:
>        * Changes required to code that uses apr_table_elts() (on the order
>          of half a dozen calls in Apache 2.0, and occasional usage in the
>          handful of large 3rd-party modules that I've checked)

This helps users of apr_table_t in general, but most of those users should
be using apr_hash_t instead. The best thing is to encourage them to change
their data type. Optimizing apr_table_t simply reduces their impetus to
change their code.

The apr_table_t is interesting in that it can keep multiple values for a
key. That is only really used for headers, and that can be best-solved by
using a new type.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message