Using optimized Vertx HTTP header names #37615
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Another low hanging fruit: vertx AsciiStrings constant in Httpheaders have constant and cached case-insensitive hashcodes, which make them faster under pretty much any circumstances.
The benefit is to drop to ~0 the ~2.87% cost reported in plaintext with reactive routes at
Moving to
contains
bring another additional benefit: a reduced allocation pressure, because Vertx multimap'sget
force allocating aString
out ofAsciiString
's value (which is theAsciiString::toString
calls in the flamegrah).The header matching cost of
HeadersMultiMap::get0
instead (inAsciiString::contentEqualsIgnoreCase
) depends by NOT using a constAsciiString
header values.Not a big, but ~3% less overall is sensible, especially because, looking a finer picture of encoding and sending back the response in the same test, it's relevant for
11.20%
of the cost, on par of encoding the content in the buffer to be sent back (which is a small content, but still...).