On Sun, Nov 04, 2001 at 07:05:17PM -0800, Greg Stein wrote: > On Sun, Nov 04, 2001 at 03:00:43PM -0800, Brian Pane wrote: > >... > > 2. Change the performance-sensitive fields in the httpd's request_rec > > from apr_table_t (like r->headers_in) to some different data type > > (e.g., "ap_http_headers_t") that supports O(log(n)) or O(1) get/set > > operations > > Pros: > > * Performance improvement for the httpd > > * Other code that uses apr_table_t isn't affected > > Cons: > > * Lots of changes required to the httpd core and all modules > > This is the most optimal approach. You can build a structure that is O(1) > for the common headers (by using tokens for the headers rather than > strings). Other headers can also be heavily optimized through a hash lookup. > I think this custom type would be a wrapper around an apr_hash_t. > > > 3. Keep using apr_table_t for the fields in request_rec, and redesign > > the internals of apr_table_t to support O(log(n)) access > > Pros: > > * Performance improvement for the httpd > > * Almost no impact on code that uses APR > > Cons: > > * Changes required to code that uses apr_table_elts() (on the order > > of half a dozen calls in Apache 2.0, and occasional usage in the > > handful of large 3rd-party modules that I've checked) > > This helps users of apr_table_t in general, but most of those users should > be using apr_hash_t instead. The best thing is to encourage them to change > their data type. Optimizing apr_table_t simply reduces their impetus to > change their code. > > The apr_table_t is interesting in that it can keep multiple values for a > key. That is only really used for headers, and that can be best-solved by > using a new type.
+1 I think #2 is the better way to go in the long run, and I am willing to help with the extra work. -aaron
