Skip to content

Performance optimizations inspired by lxin/quic kernel QUIC#13

Open
endel wants to merge 5 commits intomainfrom
perf-experiment
Open

Performance optimizations inspired by lxin/quic kernel QUIC#13
endel wants to merge 5 commits intomainfrom
perf-experiment

Conversation

@endel
Copy link
Owner

@endel endel commented Mar 19, 2026

Summary

Performance optimizations inspired by the Linux kernel QUIC implementation (lxin/quic). All changes are backwards-compatible, all 460 tests pass, and Go ↔ Zig WebTransport interop verified in both directions.

  • Bitmap-based packet number tracking — O(1) duplicate detection via fixed 4096-bit sliding-window bitmap (replaces O(n) RangeSet scan). Zero heap allocation (512 bytes inline). Inspired by kernel pnspace.c.
  • HyStart++ (RFC 9406) — Detects RTT increases during CUBIC slow start to exit before first packet loss, reducing bufferbloat. Adds Conservative Slow Start (CSS) phase with round-based RTT sampling.
  • Sub-millisecond pacing — Inline Thread.sleep() for pacer delays < 1ms in the send loop, bypassing the event loop's ms-only timer resolution. Similar to kernel's hrtimer approach for pacing.
  • FrameSorter inline fast path — In-order stream data stored in a fixed 1500-byte inline buffer, skipping hash map insert/lookup/remove on the common path. Inspired by kernel's slab cache pattern.
  • O(1) swapRemove in FrameSorter.pop() — Replaces orderedRemove (O(n)) with swapRemove (O(1)) since chunk map order is irrelevant for keyed lookup.

Test plan

  • All 460 unit tests pass (zig build test)
  • Go WT client → Zig WT server: bidi + datagram echo
  • Zig WT server → Go WT client: bidi + datagram echo
  • Release build succeeds (zig build -Doptimize=ReleaseFast)

endel added 5 commits March 19, 2026 00:57
Inspired by lxin/quic kernel pnspace.c: O(1) duplicate detection via
bit test instead of O(n) range scan. Fixed 4096-bit sliding window
(512 bytes, zero heap allocation) replaces heap-allocated ArrayList.

- PacketNumberBitmap: mark/contains O(1), getRanges scans for ACK gen
- ReceivedPacketTracker no longer needs allocator for packet tracking
- removeBelow shifts bitmap forward for ACK-of-ACK pruning
- Window auto-shifts on large PN jumps (3/4 history preserved)
Detects RTT increases during slow start before actual packet loss,
reducing bufferbloat on the first congestion event.

- Standard → CSS transition on RTT increase above eta threshold
- CSS grows by MSS/4 per ACK (vs MSS in standard slow start)
- CSS exits to congestion avoidance after 5 consecutive rounds
- CSS returns to standard if RTT stabilizes
- Round tracking via largest_sent_pn boundary
- Connection passes latest_rtt and largest_sent_pn to CC on ACK
When the pacer requests a delay < 1ms, sleep inline in the send loop
instead of returning to the event loop (which has only ms-resolution
timers). This gives ~microsecond pacing precision for high-throughput
transfers, similar to the Linux kernel QUIC's hrtimer approach.

Applied to both Server and Client event loops.
For the common case where stream data arrives in order (offset == read_pos
and no buffered chunks), stores data in a fixed 1500-byte inline buffer
instead of going through the AutoArrayHashMap. This eliminates hash map
insert/lookup/orderedRemove operations on the hot path.

Inspired by lxin/quic kernel's approach of minimizing per-frame allocation.
The pop() path still returns heap-allocated data for caller ownership
compatibility, but the push() path saves hash map overhead.
Two optimizations for the stream frame reassembly hot path:

1. Inline buffer: when data arrives in-order (offset == read_pos) and no
   out-of-order chunks are buffered, copy to a fixed 1500-byte inline
   buffer instead of going through AutoArrayHashMap operations. Avoids
   hash map insert on push for the common case.

2. swapRemove instead of orderedRemove in pop(): O(1) instead of O(n)
   for removing consumed chunks from the hash map. Order doesn't matter
   since lookup is by key (offset), not position.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant