<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>Hi all,<br></div>   I'm starting to work on refactoring HttpHeader to use LookupTable, and boy that code is a mess..<br><br></div>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.<br><br></div>Current data structures:<br></div>HeadersAttrs: static declaration of header name, header ID, header type (string/int/etc). Must be sorted by numeric value of ID<br></div>Headers: built at initialization time from HeadersAttrs, it's an array of (name, id, type, stats) structs<br>ListHeadersArr, GeneralHeadersArr, EntityHeadersArr, RequestHeadersArr, ReplyHeadersArr, etc: lists of headers ID (possibly overlapping) which are used to generate..<br>ListHeadersMask, GeneralHeadersArr, EntityHeadersArr etc: bitmaps used (only) by HttpHeaderStats to assemble different stats sets<br><br></div>I would like to turn these into:<br>headerTable: LookupTable<>::Record mapping header name to header ID, used to generate ...<br>headerLookupTable: a fast lookup table of header names to ids<br>headerStatsTable: a std::vector<HttpHeaderFieldStat> indexed by header ID to collect the statistics currently in Headers[id].stats.<br></div>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,...}.<br></div><br></div>There are some possible optimizations, but at a minimum this should help keep information more organized while introducing no performance regressions.<br></div>What do you think?<br><br></div>Thanks<br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>-- <br><div class="gmail_signature">    Kinkie</div>
</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>