You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@asyncband.apache.org by "tisonkun (via GitHub)" <gi...@apache.org> on 2026/08/27 03:03:50 UTC

Re: [PR] feat(broadcast): add unbounded MPMC channel [asyncband]

tisonkun commented on PR #117:
URL: https://github.com/apache/asyncband/pull/117#issuecomment-5433823406

   Benchmark note from an Apple M4 Max (`rustc 1.99.0-nightly`), using Divan medians and 4,096-message batches:
   
   | Workload | Asyncband | Tokio broadcast | async-broadcast |
   | --- | ---: | ---: | ---: |
   | try round trip | 37–42 ns | 15–19 ns | 22–26 ns |
   | 1 producer, then drain | 186–190 µs | 153–157 µs | 122–141 µs |
   | 8 producers, then drain | 411–451 µs | 420–451 µs | 289–320 µs |
   | fanout to 1 receiver | 181–187 µs | 154–162 µs | 117–126 µs |
   | fanout to 8 receivers | 1.39–1.43 ms | 0.20–0.23 ms | 0.81–0.86 ms |
   | fanout to 32 receivers | 4.44–4.74 ms | 0.44–0.61 ms | 2.32–2.37 ms |
   
   Tokio and async-broadcast are bounded, so the benchmark gives each enough capacity for the full batch and never exercises lag, overflow, or backpressure. This is a comparison of the common no-loss hot path, not of equivalent retention policies.
   
   The one-message reclaim change reduced Asyncband's ready round trip from roughly 54 ns to roughly 38–42 ns and improved the single-producer batch by about 25%. Producer contention is now in the same range as Tokio by 4–8 producers and remains within roughly 1.3–1.6x of async-broadcast.
   
   High fanout remains the visible scaling limit. Asyncband stays around 1.9x behind the closer lock-based async-broadcast peer, while Tokio's preallocated ring and per-slot bookkeeping can be 7–10x faster at 32 receivers. Closing that Tokio gap would require changing the receiver/reclamation algorithm rather than another local cleanup, so I have left that tradeoff visible for review instead of hiding it behind a larger redesign in this PR.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@asyncband.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@asyncband.apache.org
For additional commands, e-mail: commits-help@asyncband.apache.org