Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Expose run statistics, profiling hooks and deterministic cost counters

Abierto
  • ¿Algo no está bien?
#89 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
28/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
cli, observability

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
0
Forks
0
Merge medio
5 h 8 min
PR fusionados (30 d)
54

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de war-and-code/dircue

Todos los issues de war-and-code/dircue

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.