Consistently return StringValues.Empty instead of default for missing headers#46226
Conversation
b9b0dfd to
06f85e0
Compare
|
Could there be any performance impact here? There is lots of setting, getting and resetting of headers per request. |
|
This definitely needs a benchmark before this gets merged. |
Tratcher
left a comment
There was a problem hiding this comment.
As long as TryGetValue still returns false.
|
Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime. |
Co-authored-by: Chris Ross <Tratcher@Outlook.com>
|
HeaderCollectionBenchmark Microbenchmark results BeforeHeaderCollectionBenchmark (Non-empty values)
HeaderCollectionBenchmark.GetHeaders (Empty values)
AfterHeaderCollectionBenchmark (Non-empty values)
HeaderCollectionBenchmark.GetHeaders (Empty values)
The biggest regression is in the "Unkown (Empty values) GetHeaders" microbenchmark which reads 3 known headers and then 8 unknown headers from the underlying "unknown" generic dictionary. This went from approximately 55 to 70 nanoseconds. Before this returned The next biggest regression is in"Common (Empty values) GetHeaders" microbenchmark which reads 18 known headers from fields within the source-genned dictionary. This went from approximately 34 to 39 nanoseconds. The microbenchmark results for setting and reading non-empty values seems unnaffected. I plan to merge this PR considering it fixes a functional inconsistency and only causes a minor performance regression when reading a lot of unset headers. We can keep an eye on the automated benchmarks after this is merged. @sebastienros |
Fixes #44509