httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: What to do about tables?
Date Mon, 05 Nov 2001 05:02:36 GMT
On Sun, Nov 04, 2001 at 07:05:17PM -0800, Greg Stein wrote:
> 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.

+1

I think #2 is the better way to go in the long run, and I am willing
to help with the extra work.

-aaron

Mime
View raw message