Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Benchmark long-lived PET sessions, real concurrent resolves, and inventory scaling

Ouverte
#533 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
github-actions, rust

Piste de recherche

Start with crates/pet/tests/e2e_performance.rs and .github/workflows/perf-tests.yml, including the linked cold/warm summary and concurrent-resolve test; review dependencies #531, #529, and #530 before designing the workload. Done means CI runs reproducible long-lived and actually concurrent scenarios, catches identity replacements, reports calibrated latency/resource measurements, and documents fast versus stress invocations.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

Tracking plan: #528
Priority: P2, required before structural performance optimization. Evidence: source inspection and existing benchmark inventory.

Problem

The gated summary starts a fresh PET process for both members of every cold/warm pair. It measures persisted-cache warmth, not repeated operations in a long-lived VS Code session. The function named test_concurrent_resolve_performance actually resolves sequentially, and the workflow selects only the summary test. Inventory checks compare counts, not identities.

The exact-audit-revision release workload contains only 5 environments on Linux, 8 on Windows, and 10 on macOS. This cannot establish bounds on thread growth, cache retention, or large workspace behavior. Existing real-manager benchmarks remain valuable and should not be replaced.

Sources: cold/warm summary, sequential concurrent-resolve test, performance workflow.

Scope

Add a deterministic fixture workload alongside the installed-manager benchmark. Separate process-cold/disk-warm/same-process-warm scenarios, and exercise actual overlapping refresh/resolve/configure activity. Sweep representative inventory/workspace sizes (for example 1, 10, 100, and 1000), with expensive stress/soak variants isolated from the fast PR gate if necessary.

Measure client latency, first-result latency, peak workers/threads, subprocess counts, cache/resource growth, and retained memory where reliable platform APIs exist. Compare normalized environment/manager identities, not just counts. Keep diagnostic output privacy-safe and ensure measurement does not backpressure the timed transport.

Acceptance criteria

  • CI runs a repeated-refresh workload against one server process and an actually concurrent resolve workload; test naming and selection match behavior.
  • Create/delete/edit/alias-churn scenarios verify fresh, correctly identified environments in a long-lived process.
  • Inventory assertions detect one environment disappearing and another replacing it even when counts match.
  • Size/concurrency sweeps produce usable latency and resource measurements with explicit sample counts and reproducible fixtures.
  • Resource expectations/budgets are calibrated from measurements rather than arbitrary performance claims or unstable host-wide counters.
  • Fast deterministic checks remain PR-friendly; longer stress runs have a documented invocation and CI schedule/entry point.

Dependencies

Depends on #531 for accurate timing definitions and #529 for reliable process teardown. Reuse the subprocess fixtures/cleanup contract from #530. Outputs establish the baseline for bounded scheduling, output-lock isolation, and Poetry indexing under #528.

Langage dominant
Rust
Étoiles
207
Forks
45
Merge moyen
3 j 12 h
PR mergées (30 j)
11

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/python-environment-tools

Toutes les issues de microsoft/python-environment-tools

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.