> -----Original Message----- > From: Brian Pane [mailto:[EMAIL PROTECTED]] > Sent: Sunday, November 11, 2001 8:15 PM > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] apr_table WAS: What to do about tables? > > My +1 would be non-binding, but IMHO it makes sense to keep > optimizing your new version. With the changes to make > apr_table_elts return const (my patch and Justin's update > to it), it will be possible to drop in an index-based > implementation of tables in the future without breaking > backward compatibility. > > Based on this latest set of benchmarks, my suggestion is: > * Tune the index code until the sequential set and > random get cases can outperform the old code. (These > are both common cases in Apache.) > * Then plug the new code into a copy of the httpd to > see the effect on overall performance. > Here is the drop-in replacement for apr_table that uses hash indexes to table entries. I've tested the code to the current httpd from cvs. Well, the performance gain isn't as high as I expected (or my testing approach is wrong). Using ab the total response is aroud 1% or more faster then original, but the connection, processing and waiting have 16 % less values (If I calculated that correctly). Someone has the idea how to measure those precisely? MT.
apr_tables.h.diff
Description: Binary data
apr_tables.c
Description: Binary data
