Improve performance of HTTPHeaders.subscript(canonicalForm:)
#1952
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Lukasa
requested changes
Sep 13, 2021
Davidde94
reviewed
Sep 13, 2021
Comment on lines
+546
to
+554
| case UInt8(ascii: " "), | ||
| UInt8(ascii: "\t"), | ||
| UInt8(ascii: "\r"), | ||
| UInt8(ascii: "\n"): | ||
| return true | ||
|
|
||
| default: | ||
| return false | ||
| } |
There was a problem hiding this comment.
Apparently two are missing:
- Vertical tab
\v - Form feed
\f
There was a problem hiding this comment.
I'm disinclined to make this more complex. We're only really trying to catch the OWS rule from the HTTP -semantics draft, which strictly forbids newline characters, and I don't think we really expect to see them, so arguably we could even remove the \r and \n cases. VTAB and form-feed should also be disregarded by this loop for the same reason.
There was a problem hiding this comment.
Sounds fine to me tbh, although it says SHOULD which I'm sure someone somewhere interprets as "not necessary"
There was a problem hiding this comment.
Sure, you can put a VTAB in there: the mistake would be for us to strip it, not for us to fail to. If your VTAB makes it to the app the app is naturally going to flip its lid: what we shouldn't do is treat it as though it was accidentally equivalent to SP or HTAB.
There was a problem hiding this comment.
Should we follow up with a PR to remove \r and \n?
There was a problem hiding this comment.
(Or perhaps a good first issue)
There was a problem hiding this comment.
I think follow-up, happy to have you do it.
Do you expect a difference or is this just for completeness? (I ask because there is no difference) |
|
Completeness. We should actually add a test case that has a long header field name (more than 15 characters long both before and after the slice), because I had to do a lot of code reading to convince myself that allocating a |
Motivation: When getting the canonical form of header values any ascii whitespace is stripped from the values. The current implementation does this by doing equality checks on `Character` which is quite expensive. Modifications: - Update the `Substring.trimWhitespace()` function to trim on a UTF8 view Result: Retrieving the canonical form of header values is cheaper, significantly so when values contain whitespace.
glbrntt
force-pushed
the
gb-headers-canonical-form-perf
branch
from
e0fb43b
to
dd59d5c
Compare
|
@swift-nio-bot test perf please |
performance reportbuild id: 77 timestamp: Mon Sep 13 16:54:05 UTC 2021 results
comparison
significant differences found |
|
Relevant bits:
|
Lukasa
approved these changes
Sep 13, 2021
glbrntt
added a commit
to glbrntt/swift-nio
that referenced
this pull request
Sep 13, 2021
Motivation: Follow up to apple#1952 (comment) The OWS rule from the HTTP semantics draft only considers 'SP' and 'HTAB' to be whitespace. We also (unnecessarily) consider CR and LF to be whitespace. Modifications: - Remove CR and LF from the characters we consider to be whitespace - Update tests Result: We no longer consider CR or LF to be whitespace when trimming whitespace when producing the canonical form of header values.
Lukasa
pushed a commit
that referenced
this pull request
Sep 14, 2021
…ues (#1954) Motivation: Follow up to #1952 (comment) The OWS rule from the HTTP semantics draft only considers 'SP' and 'HTAB' to be whitespace. We also (unnecessarily) consider CR and LF to be whitespace. Modifications: - Remove CR and LF from the characters we consider to be whitespace - Update tests Result: We no longer consider CR or LF to be whitespace when trimming whitespace when producing the canonical form of header values.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation:
When getting the canonical form of header values any ascii whitespace
is stripped from the values. The current implementation does this by
doing equality checks on
Characterwhich is quite expensive.Modifications:
Substring.trimWhitespace()function to trim on a UTF8view
Result:
Retrieving the canonical form of header values is cheaper, significantly
so when values contain whitespace.
On my machine: