On Saturday 08 September 2001 16:42, Ian Holsman wrote:
> William A. Rowe, Jr. wrote:
> > From: "Brian Pane" <[EMAIL PROTECTED]>
> > Sent: Friday, September 07, 2001 2:23 PM
> >
> >>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.)
> >
> > This breaks ordering, correct? If so, -1. The apr_table_t must remain
> > ordered as pushed onto the array.
> >
> > Bill
>
> Hey Bill.
> Are you concerned about ordering of values inside of a element, or ordering
> of the elements themselves?
It doesn't matter. :-) As everybody tells me whenever I bring up this feature
of tables, it wasn't a design consideration when they were created. The fact
that tables keep elements in order has always been a by-product of the
API, not a design goal.
Now, I personally believe that since tables have always had this element ordering,
we should preserve it moving forward. However, enough others have said that
this doesn't need to be preserved, so I believe we can get past this.
However, I continue to believe that having two different hash API's in a single
library is a mistake. If we want to replace tables with hashes, then replace the
tables with hashes. That makes much more sense when reading the code.
If you want the type safety of knowing that you are putting a string into the
hash, then wrap the current hash API for string specific use. This can be
done with less code changes in APR. It also has the benefit of being able to
read the httpd code, and knowing that you are using a hash table.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
