apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: Frankentables
Date Sun, 11 May 2003 11:28:29 GMT
Brian Pane <brian.pane@cnet.com> 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

View raw message