Establish runtime ownership and task-churn baselines

[leynos]

Summary

Establish reproducible baselines for the hot paths covered by Epic #635 before changing their ownership topology.

The refactor is primarily justified by clearer lifetime boundaries, but it also claims reductions in atomic refcount operations, allocations, route preparation, and scheduler task churn. Capture enough evidence to distinguish a real improvement from an attractive ownership diagram.

Scope

Add focused benchmarks or instrumented test harnesses for:

1. Connection actor event processing

   • process a fixed number of queued frames through the actor loop;
   • cover cancellation disabled and cancellation triggered;
   • record throughput and allocation count where practical.

2. Push handle send path

   • uncontended high- and low-priority sends into a draining queue;
   • queue-full/backpressure path separately;
   • avoid rate-limiter timing dominating the ownership measurement.

3. Application connection startup

   • connect and close many short-lived connections;
   • run with representative route and middleware counts;
   • count factory invocations and middleware-chain transformations;
   • capture latency/allocations before and after one-time application preparation.

4. Client pool acquisition

   • uncontended acquire/drop for pool sizes 1, 4, and 16;
   • contended acquisition under FIFO and round-robin policies;
   • count scheduler task creation or otherwise prove task count remains stable;
   • record allocations and latency distributions.

Method

• Reuse existing Criterion and allocation-counting support where it fits rather than introducing a second benchmark framework.
• Keep transport I/O out of microbenchmarks unless the scenario is explicitly connection startup.
• Record compiler profile, feature set, pool size, queue capacity, and runtime flavour.
• Prefer black-box behavioural counters over source-code grep assertions.
• Store a concise baseline table in the benchmark module documentation or a dedicated document under docs/, with the exact command required to reproduce it.

Acceptance criteria

• A benchmark or instrumented harness exists for each of the four scopes above.
• The current implementation has a recorded baseline on one named development machine or CI runner class.
• Factory invocation and middleware transformation counts are directly asserted, not inferred from timing.
• Pool scheduler task creation is directly observable through test instrumentation or a stable runtime counter.
• Allocation measurements identify whether nested Arc removal changes allocation count as expected.
• The harnesses remain useful after the refactor and can compare old/new implementations without rewriting the scenarios.
• Benchmark results do not become correctness gates with brittle absolute timing thresholds; regression policy uses ratios or manually reviewed evidence.

Non-goals

• Proving that every atomic operation has a measurable end-to-end impact.
• Replacing existing codec performance benchmarks.
• Treating performance evidence as a substitute for ADR review.

Dependencies

This issue can land before ADR decisions are accepted and should precede the larger implementation work under #637 and #638.

References

• Epic Epic: Align Tokio task boundaries with ownership boundaries #635
• ADR 011 proposal ADR 011 proposal: Runtime ownership and task-lifetime boundaries #636
• ADR 012 proposal ADR 012 proposal: Prepared application templates and connection-local runtimes #637
• ADR 013 proposal ADR 013 proposal: Single-owner client-pool scheduler and slot graph #638
• benches/
• wireframe_testing/src/codec_benchmarks/
• src/connection/mod.rs
• src/push/queues/handle.rs
• src/server/connection_spawner.rs
• src/client/pool/

[coderabbitai]

🔗 Related PRs

leynos/chutoro#143 - HNSW packed-index neighbour evaluation (2.3.1) [merged]
#540 - Approve the actor and codec-driver boundary (10.1.3) [merged]
#552 - Align roadmap footnotes with the roadmap grammar [open]
#612 - Kill mutation-testing survivors and widen scaffolding excludes (#566, #567, #569, #570, #593, #595, #598) [merged]
leynos/cuprum#232 - docs: mark #125 FD-ownership hazard resolved in roadmap 8.1 (#125) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!