apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Frankentables
Date Tue, 06 May 2003 04:29:13 GMT


Forwarding on Joe Schaefer's behalf. For some reason his emails don't come 

On May 01 2003 Joe Schaefer wrote:

I've put together a patch for apr_tables.[ch] that melds
a number of ideas together from past apr discussions
on apr_table optimizations.  The biggest change
is to reorganize the (internal) red-black tree
implementation by including a tree-node in the

   struct apr_table_entry_t {
     const char *key;
     const char *val;

     apr_uint64_t key_checksum; /* 8 chars wide */
     int key_offset; /* number of key chars placed in checksum
                      * (0-8), or -1 if entry is "dead" */

     enum {RED, BLACK} color;
     int tree[4];        /* LEFT RIGHT UP NEXT */

and in apr_tables.c, I added some callbacks to the table
struct, which are really necessary for httpd-apreq-2:

   struct apr_table_t {
     apr_array_header_t *a;
     apr_table_copier_t *copy; /* callback for copying table values */
     apr_table_merger_t *merge; /* callback for merging table values */

     int ghosts;
     int root[TABLE_HASH_SIZE];

The patch is rough, but light testing suggests it works.
is at


Other adding a few additional functions to the API,
(and momentarily breaking APR_OVERLAP_TABLES_SET),
the biggest API change that stands out in my mind is:

   - APR_DECLARE(const apr_array_header_t *)
   -             apr_table_elts(const apr_table_t *t);
   + APR_DECLARE(const apr_array_header_t *)
   +             apr_table_elts(apr_table_t *t);

The current patch postpones any reindexing & shuffling
of table_entries until it's absolutely necessary-
which is basically whenever apr_table_elts is called.

If this patch looks promising, I'd be happy to clean it
up and submit it to apr.

Thanks alot.
-- Joe Schaefer

View raw message