apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] Turn apr_table_t into a hash table
Date Sat, 08 Sep 2001 20:20:00 GMT
On Saturday 08 September 2001 11:29, Brian Pane wrote:
> Ryan Bloom wrote:
> >On Friday 07 September 2001 14:23, Brian Pane wrote:
> >>The attached patches change the apr_table_t implementation from
> >>a linear list to a hash table (not an apr_hash_t, though!).  With
> >>this change, I'm seeing a ~3% improvement in throughput when
> >>delivering a 0-byte file over the loopback on Linux.  (I used this
> >>0-byte test case to measure the inherent overhead in the httpd, without
> >>transmission time clouding the results.)
> >
> >I dislike this.  Why are we putting a second hash table into APR?  If we
> > want to use a hash, then ues an apr_hash_t.  If apr_hash_t doesn't
> > support something that we MUST have to do this, then fix apr_hash_t. 
> > Having two different hash alorithms in APR, one of them hidden under a
> > tables API, seems kind of hackish to me.
>
> Are you arguing in favor of using apr_hash_t in the implementation of
> apr_table_t,
> or using apr_hash_t in place of apr_table_t in the request_rec?  I'm
> comfortable
> with the former, but not the latter.

The latter.  Having two API's to the same functions should only be done
as a stop-gap.  Also, a LOT of modules using the apr_table_elem macro
to get the elements from a table.  Turning that into an API would break a
lot of people.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message