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. Cheers, -g -- Greg Stein, http://www.lyra.org/
