Explore MPMC queue contention, wakeup, and storage optimizations
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- rust
調査の方向性
まず asyncband/src/mpmc/queue.rs と benchmarks/ecosystem/mpmc 配下の既存のベンチマークを読みます。列挙されたプロデューサー/コンシューマーのトポロジー全体で、有界キューと無界キューの比較可能な測定結果を確立し、その後、関連する cargo x ワークフローと Miri を使って、キャンセル、切断、配信、容量、Waker のリグレッションを確認します。完了の条件は、公開 API やキューの契約を変更せず、スループット、レイテンシ、アロケーションまたはメモリについて再現可能な結果を伴う、焦点の絞られた、独立してレビュー可能な改善です。
索引モデルが issue の本文から書いたものです。
説明
Goal
Explore measurable performance improvements to the competing MPMC queues introduced in #265. Preserve their delivery, strict bounded capacity, cancellation, and disconnection contracts. The existing mutex-based implementation is a valid baseline; a lock-free rewrite is not a prerequisite.
Candidates to investigate
- Queue and waiter coordination. Shared uses a queue mutex plus separate sender and receiver semaphores, each with its own waiter lock. Profile lock acquisitions, cache contention, and retries after a notified task loses the race. Compare this with keeping queue state and waiter bookkeeping under one mutex before introducing more elaborate synchronization.
- Separate bounded and unbounded internals where useful. Both currently share
capacity: Option<usize>and both semaphore fields, although unbounded sends never wait for capacity. A smaller unbounded state and a bounded-specific capacity model may simplify hot paths. Public endpoint types can stay unchanged. - Bounded storage allocation. The current
VecDequegrows lazily while the queue mutex is held. Compare preallocation or a fixed-capacity buffer with the current approach, including construction cost and large, mostly empty capacities. Preserve the exact requested logical capacity. - Unbounded burst handling and memory retention. Measure allocation frequency and retained memory after a burst drains. Investigate chunked storage, incremental reclamation, or limited internal batching if measurements justify them. MPSC's receiver-private batch relies on a unique receiver; do not copy it into MPMC without preserving message accessibility and correct cancellation/drop behavior for competing receivers.
- Waiter allocation and scheduling overhead. Profile repeated registration, redundant waker clones, and wake-to-poll round trips under empty/full transitions. Optimize only measured costs while preserving notification transfer on cancellation and the Waker contract in
AGENTS.md.
These are hypotheses to test, not a requirement to implement every candidate. Coordinate capacity-accounting changes with the bounded-reservation work in #297.
Measurement and acceptance
Start with the existing MPMC ecosystem benchmarks, which compare asyncband, async-channel, and Flume across 1P/1C, 1P/8C, 8P/1C, and 8P/8C. Keep producer/consumer behavior and message counts comparable.
- Cover bounded and unbounded queues, small and larger capacities, steady traffic, bursts, and idle-to-active transitions. Include workloads where receivers stop at different times rather than only consuming equal quotas.
- Report reproducible before/after results with commit, toolchain, hardware, runtime/thread setup, and benchmark parameters. Measure throughput and latency; include allocations and peak/retained memory for storage changes.
- Explain which cost each change removes and report regressions across the other topologies. Land independently reviewable improvements rather than one combined backend rewrite.
- Preserve deterministic cancellation and disconnect regressions, exactly-once delivery, and bounded-capacity checks; use the relevant
cargo xworkflows and Miri where appropriate.
Follow-up to #211 and #265; part of #206. This issue does not add public APIs.
- 主要言語
- Rust
- スター
- 277
- フォーク
- 44
- 平均マージ
- 1日 1分
- マージ済み PR（30日）
- 40
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/asyncband のほかの issue
-
enhancement good first issue help wanted
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
apache/asyncband#324 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement question
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
apache/asyncband#312 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
apache/asyncband#272 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
Explore ManualResetEvent waiter storage and state fast paths再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンenhancement good first issue help wanted
難易度 5/5 1週間以上 初心者へのやさしさ 38/100
apache/asyncband#252 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
apache/asyncband#224 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
apache/asyncband の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
antithesishq/bombadil#361 ·
メンテナーはふだん 1 日以内に返信
-
test(executor_l0): assert execute() TaskOutcome, not only bus events / 断言 execute() 返回的 TaskOutcomeオープンtype:debt
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
skaiy/wild_agentos#425 ·
メンテナーはふだん 1 日以内に返信
-
Default-import note suggests `import * as process` for velt:process, which does not name the builtinオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
bug ticket
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
cratestack/cratestack#1154 ·
メンテナーはふだん 1 日以内に返信
-
status:needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信