Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Expose run statistics, profiling hooks and deterministic cost counters

Aperta
  • Qualcosa non va?
#89 2 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
28/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
cli, observability

Direzione di ricerca

Start at the CLI entry points behind capabilities --cli, then read the guide requirements for the new flags and stats JSON schema. Use the golden corpus and the metamorphic repeated-run and worker-count checks as the validation targets; done means the documented counters, profiles, progress output, and effective settings meet the listed overhead and determinism requirements.

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

Descrizione

enhancement follow-up

Why

dircue has no user-facing performance visibility. There are no --stats, --cpuprofile, --memprofile, --trace or progress options, and non-test code doesn't import runtime/pprof at all. So:

  • users can't see where time or memory went, or which settings were in effect;
  • CI can only measure noisy wall time from outside the process;
  • a 4-minute kernel run shows nothing until it ends.

The 30× Git-path metrics cliff (#73) went unnoticed partly because nothing reported bytes inflated, cache behavior or worker utilization.

FFmpeg is the model here: -benchmark prints user/system/real time and max RSS; -stats/-progress report live progress in human or machine form; -report writes a full log.

Proposal

  • --stats, printed to stderr, and --stats-json FILE, broken down per phase and per module:
    • wall time, user/system CPU, and peak RSS (process);
    • Go heap and GC count/pause (runtime/metrics) and allocations;
    • bytes read by source (filesystem vs Git) and files opened;
    • Git objects read and inflated, delta resolutions and a chain-depth histogram, object and pack cache hits/misses;
    • worker utilization and queue wait;
    • budget hits.
  • Logical vs physical counters. Logical work (files selected, logical bytes requested, parse counts) depends only on input and settings. Physical work (bytes actually read or inflated, cache hits/misses, repeated delta resolutions) is an observed cost and can vary with worker scheduling, cache eviction and pack layout. CI gates on logical counters, and on physical costs only under a pinned pack layout and controlled cache conditions (#90). See the implementation note in the comments.
  • Profiling hooks: --cpuprofile, --memprofile, --blockprofile, --mutexprofile and --trace FILE, for users and for CI artifacts.
  • --progress[=json]: periodic progress on stderr (phase, files and bytes done/total, elapsed) for long runs.
  • Statistics are run metadata and never enter the deterministic map payload (#74). They go to stderr, a separate file, or a clearly separated non-deterministic section.
  • Every run can record its effective settings and their origin (default, preset, flag or file). See #91.

Acceptance

  • The flags above, documented in capabilities --cli and the guide. Stats JSON has its own schema.
  • Logical-work counters and output stay identical across repeated runs and worker counts (tested metamorphically). Physical costs are reported as observed values, not promised to be invariant.
  • Overhead with stats disabled is unmeasurable, and ≤ 2% with stats enabled on the golden corpus.
  • #73 and #39 use these counters and profiles as their evidence.

Part of the 1.0 quality program: #83. Epic: #81.

Lingua principale
Go
Stelle
0
Fork
0
Merge medio
5h 8m
PR unite (30g)
54

Preparare l'ambiente

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 war-and-code/dircue

Tutte le issue di war-and-code/dircue

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.