From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Saturday, September 08, 2001 8:32 AM
> 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.
Agreed. Because of the ordering issues (with insertion order) that I brought up
earlier, this is probably not the best place to introduce such a feature.
apr_hash_t should be sufficient, and if it is not, please suggest improvements
to the apr_hash_t api :)
Bill
