apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: [PATCH] Turn apr_table_t into a hash table
Date Sat, 08 Sep 2001 20:51:06 GMT
Ryan Bloom wrote:

>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
>>or using apr_hash_t in place of apr_table_t in the request_rec?  I'm
>>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.
I disagree.  It's inevitable to have two APIs, as long as we have two
'table' types with very different semantics.

apr_table_t is statically typed (uses char*), and apr_hash_t isn't (uses 
If we did a direct replacement of apr_table_t with apr_hash_t in the httpd,
we'd be sacrificing static type-safety for a lot of code.

>  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.
My patch covers all the changes needed for the core modules.  Do you have
any info on the number of 3rd-party modules for 2.0 that use apr_table_elem?


View raw message