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