[squid-dev] [RFC] Refactor HttpHeader
Kinkie
gkinkie at gmail.com
Wed Jul 29 21:10:25 UTC 2015
Hi all,
I'm starting to work on refactoring HttpHeader to use LookupTable, and
boy that code is a mess..
Since it's going to take significant effort, I'd like to get feedback on
the changes I'd like to implement, so not to end in long discussions later.
Current data structures:
HeadersAttrs: static declaration of header name, header ID, header type
(string/int/etc). Must be sorted by numeric value of ID
Headers: built at initialization time from HeadersAttrs, it's an array of
(name, id, type, stats) structs
ListHeadersArr, GeneralHeadersArr, EntityHeadersArr, RequestHeadersArr,
ReplyHeadersArr, etc: lists of headers ID (possibly overlapping) which are
used to generate..
ListHeadersMask, GeneralHeadersArr, EntityHeadersArr etc: bitmaps used
(only) by HttpHeaderStats to assemble different stats sets
I would like to turn these into:
headerTable: LookupTable<>::Record mapping header name to header ID, used
to generate ...
headerLookupTable: a fast lookup table of header names to ids
headerStatsTable: a std::vector<HttpHeaderFieldStat> indexed by header ID
to collect the statistics currently in Headers[id].stats.
headerDescription: a std::vector keyed by header ID containing header type
(currently in Headers[id].type), possibly header name (if useful), a
bitfield noting if HTTP_HDR{LIST,GENERAL,REQUEST,REPLY,...}.
There are some possible optimizations, but at a minimum this should help
keep information more organized while introducing no performance
regressions.
What do you think?
Thanks
--
Kinkie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20150729/b16f708a/attachment.html>
More information about the squid-dev
mailing list