As we approach GA for Apache 2.0, the apr_table_t code is
one of the largest remaining performance bottlenecks. I'm
willing to spend some time fixing this, but because there
hasn't been a solid consensus when this issue has come up
in the past, I'd like to get feedback on strategy first.
I can think of three general approaches:
1. Do nothing
Pros:
* No new development or regression testing required
* No API changes that affect 3rd party modules
Cons:
* O(n) implementations remain for table get/set functions
* Because apr_table_elts() exposes the array-based internals
of apr_table_t, we won't be able to make the optimizations
in a later release without breaking code that uses that macro.
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
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)
Comments?
Thanks,
--Brian
