Repository navigation
h2c: -1.6% req/s on epoll (-1.0% io_uring) against 0.1.3 #90
Description
Found in the 0.2.0 end-to-end run on the x86 box (bench/results/20261023-v0.2.0-e2e): 1 CPU, h2load h2c with 256 connections x 10 streams, medians of 3, rested and interleaved, c259b05 (0.1.3) vs 91c7378 (0.2.0).
| 0.1.3 | 0.2.0 | |
|---|---|---|
| epoll req/s | 647.2k | 636.6k (0.984) |
| epoll p99 | 4.28 ms | 4.34 ms (1.01) |
| io_uring req/s | 674.1k | 667.6k (0.990) |
| io_uring p99 | 4.22 ms | 4.28 ms (1.02) |
Within ±3% but consistent in every round, so likely real. Candidates: the API-hardening checks on the request path (MisuseError guards, the flattened options) and the zio upstream merge (#82). Minor, so deferred; I'll bisect with a perf profile when I next touch the HTTP/2 path.
Activity
xuckless commentedon Oct 28, 2026
Before bisecting, I'll re-check this with fixed-count instructions:u per request (one executor, exactly N requests). That becomes a standing box column in S1.5; the method is on #103. If the 1.6% rate delta comes with equal instructions, it points at code layout rather than work.
If instructions do differ, the bisect stays. The h2 request path itself is replaced by the HTTP/2 takeover (M1-M6 in S2), so I'll only fix something here if it is cheap and outside the code the takeover replaces.
xuckless commentedon Nov 1, 2026
Superseded by 0.5.0. On HttpArena's machine (MDA2AV/HttpArena#1692, saved run) baseline-h2c is +47% to +70% against v0.1.2's published results (11.7-12.3M req/s), and on my box h2c uses 16,870 instructions per request on 0.5.0 against 19,390 on v0.1.2 and 19,709 on 0.4.2 (fixed-count
instructions:u, bench/results/20261101-rc-ab5). The -1.6% this issue tracked is gone.