Disk polling: measure task construction and completion payload costs

Aperta
  • Qualcosa non va?
#4,179 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend, performance

Direzione di ricerca

Inizia da core/shard/src/poll.rs::read_poll e core/shard/src/poll/completion.rs::PollCompletionSender::complete. Analizza un binario ottimizzato della release corrente per determinare le dimensioni di future e payload, il numero di allocazioni e gli stack di creazione dei task, quindi riutilizza la diagnostica del parent con e senza scritture. Il lavoro è completato quando ogni modifica della rappresentazione è giustificata da un costo materiale, preservando al contempo il rilascio delle reservation, la cancellazione, il completamento tardivo, i controlli di history, l’accettazione da parte dell’owner e la guardia per il requester disconnesso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

performance server

Part of #4174, which records the shared profile revisions, workload and evaluation criteria.

read_poll transfers an owned PollPlan into a detached future, and PollCompletionSender::complete constructs Box<PollCompleted>. Determine whether their current copying or allocation costs justify a representation change.

In the historical candidate's two captures without writes, __memcpy_generic samples with disk task creation as the first application caller accounted for 2.00 and 1.82 µs of CPU per completed poll. Matching libc debug symbols resolved these samples. They identify copying during task creation, but neither the copied object nor the full construction cost or elapsed cost of boxing.

This is a lower priority lead: metric ownership and numeric history changes have since reduced carried state. Confirm that the old signal survives before selecting a change.

  • Inspect optimized future and payload sizes, allocation counts and task creation caller stacks for an exact current release binary.
  • Follow real ownership transfers through plan construction, execution, completion delivery and destruction. Account for copying, allocation placement and retained bytes throughout those lifetimes.
  • Reuse the parent's diagnostics with and without writes. If a material cost remains, compare one representation change through completed polls using the shared timing and validation rules.

Preserve reservation release, cancellation behavior, late completion handling, history checks, owner acceptance and the disconnected requester guard. Removing boxing can enlarge futures or queue entries; pooling can increase retention. A standalone allocator benchmark omits these ownership and scheduling effects, and fewer allocations alone do not establish a useful improvement.

Lingua principale
Rust
Stelle
5.2k
Fork
502
Merge medio
3g 4h
PR unite (30g)
157

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/iggy

Tutte le issue di apache/iggy

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.