Joe Schaefer wrote:
Greg Ames <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
Just looking over the 2.0
source, it looks to me like r->headers_in is an empty
apr_table prior to the apr_table_overlap() call at the
end of get_mime_headers_core().
I'll take your word for it.
Please treat the following comments with the appropriate
level of contempt, since at this moment apreq_tables are
still vaporware...
I've written a table implementation for apreq-2 that
superimposes an array of binary trees over the table's
array entries. It allows for "dead entries" to appear in
the array, so that "restacking" the table entries
(and reindexing the superimposed tree nodes) wouldn't
be necessary when table entries are unset or merged.
The apr_table_overlap call in get_mime_headers_core()
effectively merges all duplicate input headers, and it
uses red-black trees to do so. If apr_tables were able
to tolerate "dead entries", it might be possible to port
some of the apreq_table implementation to apr (assuming
the apreq_table approach proves to be more efficient).
Definitely sounds interesting, if it proves faster than
the current APR tables. One other thing that might speed
up apr_table_overlap is to eliminate the red-black trees.
I added them back when the tables themselves had no
indices. Now that each apr_table_t contains an internal
index (a crude one, but fairly effective in practice),
we might be able to accelerate the overlap operation by
using that index in place of the red-black trees.
Brian
