apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject What to do about tables?
Date Sun, 04 Nov 2001 23:00:43 GMT
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



Mime
View raw message