bench: measure InboundDispatch and OutboundRoutes (design 054 §5)

[lxsaah]

Stage 7 of the 054 implementation plan (a checkpoint). It puts InboundDispatch and OutboundRoutes under the allocation gate and adds an informational timing bench for the outbound wake-up path.

Change

b0_alloc_connector: nine new rows. The old rows stay until stage 16. EXPECTED and data/baselines/b0_alloc_connector.json are updated together; the baseline diff only adds lines, so the old rows are unchanged.

Row	Target	Measured
inbound_dispatch	0	0.00
inbound_dispatch_pattern	0	0.00
inbound_dispatch_keyed_known	0	0.00
inbound_dispatch_keyed_new	1 (first sighting of a key)	1.00
outbound_next_static_topic	0	0.00
outbound_next_written_topic	0	0.00
outbound_next_owned	1 (owned serializer)	1.00
outbound_next_round_robin (8 routes, all ready)	0	0.00
outbound_next_parked (every pull parks and is woken)	0	0.00

In the parked row, the transport pulls in its own task, and the producer writes one value and yields until it has been pulled. The transport calls next() again before the next value exists, so every pull after the first parks and is woken.

New b1_outbound_wakeup: informational, registered in aimdb-bench/Cargo.toml, not part of bench-gate. It is ported from the spike's parked scenario:

• One busy route among 1, 8, 64 and 256, on a current-thread runtime.
• Two columns: a task per route over Reader::recv (no pump_sink, so it still compiles after stage 16) and OutboundRoutes::next.
• Nanoseconds per message, median of 5 runs, plus allocations per message.

Timing check: please rerun on a quiet host

The plan's bounds, from one run:

1. OutboundRoutes at 256 routes within 10 % of its 8-route figure.
2. Within about 150 ns of the task-per-route column at 256 routes.

The one clean local run (devcontainer):

Routes	Task per route	OutboundRoutes
1	481	637
8	500	640
64	482	641
256	481	690

• Bound 1 is met: 690 vs 640 ns, +7.8 %.
• Bound 2 is missed: 209 ns at 256 routes. The spike measured 112 ns.

A same-host run of the spike's bare bitmap (copied in temporarily, not committed) gave 617 ns at 8 routes against OutboundRoutes' 640 ns. That suggests serialization and staging add only about 20 ns, and that most of the gap is this host rather than OutboundRoutes. Later runs were unusable because other builds loaded the host (spreads up to 5.7 µs), so this isn't settled.

To rerun:

make bench-gate
cargo bench -p aimdb-bench --bench b1_outbound_wakeup

If bound 2 still misses on a quiet host, the plan says the cause is in stage 6b's hot path, and it gets fixed there before stage 8.

Timing rerun (cloud sandbox)

b1_outbound_wakeup, one busy route among N, current-thread runtime, ns per message (median, range of 5 runs), 0 allocations per message in every cell:

Routes	Task per route	OutboundRoutes
1	671 (646–689)	847 (795–915)
8	665 (655–676)	853 (636–882)
64	499 (444–510)	568 (560–628)
256	454 (442–459)	611 (576–671)

• Bound 1 (no growth with route count): met. 256 routes are below the 8-route figure, and 64 → 256 is +7.6 %. The 1- and 8-route rows are high in both columns, which looks like warm-up at the start of the run.
• Bound 2 (gap to task per route at 256 routes, about 150 ns): met, at 157 ns.
• Together with the same-host spike comparison above (about 20 ns over the bare bitmap), there is no sign of serialization or staging cost on the hot path, so stage 6b needs no change. The per-message cost against a task per route is the trade-off recorded in design §5.1.
• make bench-gate in the sandbox: all 17 rows at target. (The sandbox first needed git submodule update --init --recursive; the CI bench-gate job already checks out submodules recursively.)

Verification

• make bench-gate: passes with all 17 rows at target.
• cargo clippy -p aimdb-bench --all-targets -- -D warnings and cargo fmt --all --check: clean.
• CI does not run on PRs into feat/054-connector-boundary.

🤖 Generated with Claude Code