-
Couldn't load subscription status.
- Fork 462
Reworking Headers impl #5396
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
base: main
Are you sure you want to change the base?
Reworking Headers impl #5396
Conversation
7f431f6 to
b94d316
Compare
CodSpeed Performance ReportMerging #5396 will improve performances by 45.68%Comparing Summary
Benchmarks breakdown
Footnotes
|
8191e31 to
7f84859
Compare
|
Internal tests are failing because the refactor changes the ordering of the headers in places... will need to see if we can preserve the order but first want to see if this has a positive impact on performance overall... waiting for benchmark results to be updated. |
21b09a3 to
b59e107
Compare
|
Marking as ready for review but there are still some internal test updates I'll need to do on the internal repo. |
7ac27f1 to
7c52fb0
Compare
| 'headers/headers-errors.any.js': { | ||
| comment: 'Our validation of header names is too lax', | ||
| expectedFailures: [ | ||
| 'Create headers giving bad header name as init argument', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we did end up getting a couple of WPT improvements out of it, nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, but we'll need to make sure this doesn't count as a breaking change that'll need a compat flag.
|
Whenever this is done I want as many reviewers as we can get on this, incl Harris, Kenton, Mike, Yagiz, etc. |
0a4c8f0 to
7c52fb0
Compare
2e794b4 to
fb81688
Compare
|
Note for reviewers: while it likely is possible to get more performance gain with additional tweaks on this, the emphasis for review should be on correctness and ensuring that the revised implementation does not introduce new bugs, etc. We can tweak additional performance knobs separately in follow up PRs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only skimmed briefly but I think there's an opportunity for big gains here by taking advantage of the tables that are already available in HttpOverCapnpFactory.
38a2fab to
37b85f0
Compare
37b85f0 to
cd7bdc8
Compare
|
Further improved the revised implementation and added an additional benchmark.
|
cd7bdc8 to
95b9cbc
Compare
Bumping this |
In preparation to re-apply Headers performance improvements
Modify the kj::HttpHeaders instead and then construct the api::Headers from that.
While the common header names and indices are defined in the capnp header, they are unlikely to change often (if at all). To avoid the overhead of building the hash map at runtime and performing the hash lookups, we can hardcode the common header names in an array and use direct indexing to retrieve them. Should at least save a handful of CPU cycles.
The type is largely obsolete and was being used only to warn about invalid header names/values in Headers. However, it incurred an additional overhead when being created. This was especially non-sensical for header names since we already validate those to be proper HTTP token strings. Removing the type simplifies code and helps boost overall performance.
95b9cbc to
30f6df6
Compare
Needs careful review. It does improve performance but the impl is a bit more complex. Fiddled around with a number of other perf tweaks but nothing that really moved the needle enough to justify the increased complexity. Not entirely sold on this impl so be brutal in reviews.