Brian Pane <[EMAIL PROTECTED]> 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
