-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
introduce a separate code paths for Short Header packet handling #3534
Conversation
The new parsing function is vastly faster than the combination of header and extended header parsing: BenchmarkShortHeaderParsing-10 44192314 26.79 ns/op 48 B/op 1 allocs/op BenchmarkShortHeaderParsingOld-10 12627363 99.99 ns/op 228 B/op 3 allocs/op
2a1824c
to
4f3d3b3
Compare
Codecov ReportBase: 85.56% // Head: 85.47% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #3534 +/- ##
==========================================
- Coverage 85.56% 85.47% -0.08%
==========================================
Files 137 138 +1
Lines 10087 10221 +134
==========================================
+ Hits 8630 8736 +106
- Misses 1080 1102 +22
- Partials 377 383 +6
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Part of #3526.
This allows us to avoid the expensive code path of first parsing a
wire.Header
, then converting it into awire.ExtendedHeader
, which then has most of its field unset, since it can represent the entire complexity of a Long Header.This change brings down the allocations for receiving data significantly.
In follow-up PRs, I'm planning to:
wire.ShortHeader
struct. The 4 fields could be return values, making sure that all allocations happen on the stack