Expose run statistics, profiling hooks and deterministic cost counters

オープン
  • 何か問題がありますか？
#89 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
28/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
cli, observability

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Go
スター
0
フォーク
0
平均マージ
11時間 3分
マージ済み PR（30日）
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

war-and-code/dircue のほかの issue

war-and-code/dircue の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。