- 
                Notifications
    You must be signed in to change notification settings 
- Fork 464
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.