Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 77763 invoked by uid 500); 11 May 2003 11:26:54 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 77752 invoked from network); 11 May 2003 11:26:53 -0000 Mail-Followup-To: dev@apr.apache.org X-Injected-Via-Gmane: http://gmane.org/ To: dev@apr.apache.org From: Joe Schaefer Subject: Re: Frankentables Date: 11 May 2003 07:28:29 -0400 Lines: 38 Message-ID: References: <3EB73A19.7010803@stason.org> <1052622786.7441.40.camel@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org Mail-Copies-To: never User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Brian Pane writes: [...] > Back when I put the current checksum support into apr_table, > I found that making the checksum *too* good was detrimental > to performance, at least when using httpd-2.0 as a test case. > The problem was that apr_table_addn() is called a lot. Before > checksums, that function only had to do one if-statement and > a little bit of pointer arithmetic in the common case. The > cost of computing the 4-byte checksum was nontrivial in > comparison. So apr_table_addn() got slower, but the total time > spent in table operations was reduced. Perhaps we can find a "sweet-spot" that doesn't penalize small tables, by only engaging the checksum + red-black tree code after the table reaches a certain size? If so, my guess is that it's going to be somewhere around 8-16 elements, which most tables in httpd don't reach. [...] > If you have a chance to do any performance testing and/or profiling, > I'd be really interested in seeing the results. There's a crude set of table tests in httpd-apreq-2/t/performance.c, but basically what they tell me is that 1) Getting rid of the temporary table in ap_get_mime_headers_core is a big win. 2) For tables whose entries can be distinguished by first letter alone, the current implementation is faster. I haven't benchmarked the addn difference yet, but the penalty on the new code is certainly more substantial there. -- Joe Schaefer