Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 08 Sep 2001 11:29:05 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: [PATCH] Turn apr_table_t into a hash table
To: rbb@covalent.net
Cc: dev@httpd.apache.org, dev@apr.apache.org
Message-id: <3B9A6371.1000204@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
References: <3B993AEB.8040602@pacbell.net>
 <20010908153211.A49E046DF4@koj.rkbloom.net>

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.

--Brian