Benchmarks against tosu

• Regular reader: batching reads whole spans rather than individual fields. Linux fixtures make 21–72 backend calls per capture instead of 135–314 (lazer gameplay: 28 calls / 5,418 bytes against 268 / 1,889). This requests more bytes while making far fewer calls.
• Windows batching: read_many issues one ReadProcessMemory per run of ascending requests within a 4 KiB page, including gaps, plus a read for any short suffix. A backend call may still make several native reads; native read counts were not measured. The regular-reader synthetic harness is Linux-only; the live Windows rows below measure the combined effect.
• Filtered WebSocket fan-out: production projection and in-process fan-out use changing snapshots, a paused Tokio clock and reference byte comparisons. Identical ordered filter plans share a broadcast-pass cache (at most 64 variants / 1 MiB); properties shared across distinct plans have a work budget.
• HTTP: the HTTP path was not optimized; the microbenchmarks are 2–6% slower on both platforms, within or near their ranges. New-connection Windows requests cost about 360–370 µs.
• These are synthetic fixtures, not live clients, network transport, or whole-daemon CPU and memory. The live measurements below are separate runs.

• Both readers ran their production capture paths with zero read errors in every invocation, but they don't read identical field sets: the cycles compare equivalent production work, not identical work.
• On Linux lazer, tosu's ranked-play read returned its not-ready sentinel on every regular cycle (counted, not an error). The cycle still continued through settings, gameplay, leaderboard, and user reads, 504 reads per cycle.
• Batched captures closed the Linux settings gap. Instrumented lazer captures read settings in 9 vosu backend calls (8.3 µs) against 243 tosu API calls (67.8 µs); the regular cycle was 24 calls (19.2 µs) against 504 (155.0 µs). Stable was 24 calls (32.2 µs) against 306 (169.4 µs). These include instrumentation overhead, unlike the charts. The call units differ, neither counts syscalls, and tosu string API calls hide a second native read.
• For Linux osu!stable, the tosu harness's own 32-bit process check was relaxed: Wine runs the 32-bit osu!.exe inside a 64-bit process, and tosu's instance manager doesn't make that check.

• CPU is a percentage of one logical core.
• Resident memory is the Windows working set or the Linux resident set.
• Private memory is Windows private commit or Linux Private_Clean + Private_Dirty + Private_Hugetlb, so it is not comparable across platforms.
• Background latency covers only two cold requests per window, each on a new connection, so it mostly measures connection setup.
• tosu 4.26.2 publishes empty play data for osu-winello osu!stable when it isn't started from the osu! folder: it resolves Wine's D:\osu!.exe command line against its own working directory and can't open the map. The Linux osu!stable rows started tosu from the osu! folder, without changing tosu.

The rows exercise the closest tosu production path, not identical work:

• tosu's map calculation goes through its native lazer calculator (0.6.1-20260729-main.0), including the JavaScript bridge.
• tosu's raw-snapshot cases take error and not-ready paths on the zeroed fixture, and its lazer case rescans because the fixture fails its GameBase check.
• batch_scan calls tosu's inner scanner through an adapter, not its process-wide scan.
• tosu has no batched read API, so the read-many cases issue eight reads, and every read allocates a returned buffer.
• tosu's precise serializer surfaces four keys; vosu's fixture has 18. The serializer inputs differ in general, which is part of why serializers_cold/v2_precise favors tosu.
• On Windows, vosu's serializers_cold/v1 and stream_companion intervals are wide (6.3–11.6 µs and 9.6–15.1 µs).
• linux_process_memory and windows_process_memory only exist on their own platform.