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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
