[Webkit-unassigned] [Bug 152828] Replace HTTPHeaderMap by HTTPHeaderList

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=152828

--- Comment #3 from Alex Christensen <achristensen at apple.com> ---
(In reply to comment #2)
> (In reply to comment #1)
> > We also need to keep information about the first header with each name so
> > that set, get, contains, etc. don't have to search the whole list every time
> > they are called.
> 
> Keeping the first index would optimize the case of get and contains.
> set and remove would remain O(n), at least in a worst case scenario.
> It would also slow down append().
We should also keep track of which headers only have one header in the list with the given name, so set and remove will be O(1) for headers with a unique name.  Headers with a non-unique name will still be O(n), but remove needs to be O(n) anyways to update the structures.
> 
> I would first like to have a simple functional HTTPHeaderList with a clean
> API. Then it could be optimized internally to handle large sets.
This would be a performance regression until the optimizations are done.  I don't think we should do this.
> 
> For instance, keeping-first-index mechanism might be triggered when header
> set size is above a given threshold. 
This would make it hard to find bugs that only appear in large lists or near the threshold.  I don't think we should do this.  Optimizing for small lists is a premature optimization.
> Or it can be done lazily when a header is actually get.
This would make get slow.

Basically, we should not use data structures that assume that the number of headers will always stay small.  This is a bad assumption unless you can verify that there is no important use of many headers on the entire internet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160108/a1cbdf6f/attachment-0001.html>