-
Notifications
You must be signed in to change notification settings - Fork 124
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
perf(transport): have add_datagram take Vec<u8> #2120
Conversation
`add_datagram` takes a Quic datagram and adds it to the queue of datagrams to be sent out. Previously it would take a reference (i.e. `&[u8]`) and would allocate it into a new `Vec<u8>` before enqueuing. At the call-site the original allocation (referenced by the `&[u8]`) would go out-of-scope and thus be de-allocated. This is a wasted allocation for each Quic datagram to be send. This commit has the call-site pass the owned `Vec<u8>` down right away.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2120 +/- ##
==========================================
- Coverage 95.32% 95.31% -0.01%
==========================================
Files 112 112
Lines 36319 36316 -3
==========================================
- Hits 34621 34615 -6
- Misses 1698 1701 +3 ☔ View full report in Codecov by Sentry. |
Failed Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
All resultsSucceeded Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
Unsupported Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
|
Benchmark resultsPerformance differences relative to b780e53. coalesce_acked_from_zero 1+1 entries: No change in performance detected.time: [99.506 ns 99.840 ns 100.18 ns] change: [-0.3972% +0.3129% +0.8999%] (p = 0.38 > 0.05) coalesce_acked_from_zero 3+1 entries: No change in performance detected.time: [117.19 ns 117.55 ns 117.94 ns] change: [-0.5740% -0.0443% +0.4019%] (p = 0.87 > 0.05) coalesce_acked_from_zero 10+1 entries: No change in performance detected.time: [116.78 ns 117.19 ns 117.68 ns] change: [-0.6992% -0.1123% +0.4395%] (p = 0.71 > 0.05) coalesce_acked_from_zero 1000+1 entries: No change in performance detected.time: [96.989 ns 97.146 ns 97.323 ns] change: [-0.8335% -0.0881% +0.7050%] (p = 0.84 > 0.05) RxStreamOrderer::inbound_frame(): No change in performance detected.time: [110.97 ms 111.10 ms 111.33 ms] change: [-0.0860% +0.1653% +0.4044%] (p = 0.22 > 0.05) transfer/pacing-false/varying-seeds: No change in performance detected.time: [25.883 ms 26.792 ms 27.688 ms] change: [-6.3449% -1.6427% +3.3262%] (p = 0.50 > 0.05) transfer/pacing-true/varying-seeds: No change in performance detected.time: [34.175 ms 35.933 ms 37.725 ms] change: [-10.937% -4.4610% +2.4717%] (p = 0.20 > 0.05) transfer/pacing-false/same-seed: No change in performance detected.time: [31.879 ms 32.563 ms 33.223 ms] change: [-1.7419% +1.4026% +4.5902%] (p = 0.38 > 0.05) transfer/pacing-true/same-seed: No change in performance detected.time: [37.088 ms 39.936 ms 42.827 ms] change: [-15.168% -6.3307% +3.0117%] (p = 0.17 > 0.05) 1-conn/1-100mb-resp (aka. Download)/client: No change in performance detected.time: [113.31 ms 113.69 ms 114.05 ms] thrpt: [876.81 MiB/s 879.60 MiB/s 882.56 MiB/s] change: time: [-0.5780% -0.1062% +0.3695%] (p = 0.66 > 0.05) thrpt: [-0.3681% +0.1063% +0.5813%] 1-conn/10_000-parallel-1b-resp (aka. RPS)/client: No change in performance detected.time: [313.57 ms 317.02 ms 320.50 ms] thrpt: [31.201 Kelem/s 31.543 Kelem/s 31.891 Kelem/s] change: time: [-1.4297% +0.1767% +1.7310%] (p = 0.83 > 0.05) thrpt: [-1.7015% -0.1763% +1.4505%] 1-conn/1-1b-resp (aka. HPS)/client: No change in performance detected.time: [34.126 ms 34.338 ms 34.566 ms] thrpt: [28.931 elem/s 29.122 elem/s 29.303 elem/s] change: time: [-1.3284% -0.3843% +0.4900%] (p = 0.42 > 0.05) thrpt: [-0.4876% +0.3858% +1.3463%] Client/server transfer resultsTransfer of 33554432 bytes over loopback.
|
add_datagram
takes a Quic datagram and adds it to the queue of datagrams to be sent out. Previously it would take a reference (i.e.&[u8]
) and would allocate it into a newVec<u8>
before enqueuing. At the call-site the original allocation (referenced by the&[u8]
) would go out-of-scope and thus be de-allocated. This is a wasted allocation for each Quic datagram to be send.This commit has the call-site pass the owned
Vec<u8>
down right away.