-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a very lazy translation of headers #117
Conversation
On |
Also, I've realised that though the |
Looks like a change to Kitura/BlueSSLService@468d581#diff-92ba0ed683849bc916d3ff460ce0b4b6 |
b506932
to
c5e1312
Compare
|
a35bd56
to
3bb5347
Compare
3bb5347
to
e9ca626
Compare
A summary of the perf gains this PR gives on the different TechEmpower benchmarks (column
|
Add HeaderContainer tests in dual mode
e9ca626
to
f82886e
Compare
For the records, these are the %age gains on the different TechEmpower benchmarks:
|
This pull request proposes a very lazy translation of
HTTPHeaders
toHeadersContainer
. The difference between these structures, that matters most, is the conformance toCollection
.HeadersContainer
is aCollection
,HTTPHeaders
isn't.Conforming
HTTPHeaders
toCollection
via an extension isn't straightforward. A conformance toCollection
using the existing API leads to a very inelegant and sub-optimal implementation.In that case, the only alternative we are left with is an "as lazy as possible" translation. Inside
HeadersContainer
, we maintain an extra backing store of typeHTTPHeaders
. The existing backing store, aDictionary
lies dormant. Only when the user code tries to access theHeadersContainer
asCollection
, a translation is done and theDictionary
backing store comes to life. Subsequently, we update both the backing stores. This is to make sure there's no need for theHeadersContainer
toHTTPHeaders
translation.In short, the
HTTPHeaders
->HeadersContainer
is done very lazily and the vice versa isn't needed.