chore(bench): per-iteration phase trace for #1054 diagnosis [DO NOT MERGE]#1062
chore(bench): per-iteration phase trace for #1054 diagnosis [DO NOT MERGE]#1062carlos-alm wants to merge 3 commits into
Conversation
…ERGE] Adds [1054-trace] log lines to incremental-benchmark.ts and benchmark.ts that print the buildGraph PipelineTiming phase breakdown for every full, no-op, and 1-file iteration to stderr. The CI gate currently shows a flat ~2s/call native overhead that doesn't reproduce locally; with this trace the gate log will show exactly which phase (parseMs, edgesMs, rolesMs, etc.) eats that 2s. Throwaway branch — dispatch the publish workflow against it, read the log, then close. The trace lines go to stderr only and don't affect the JSON the gate consumes, but committing diagnostic prints to mainline benchmarks is the wrong shape long-term. Refs #1054
|
Claude finished @carlos-alm's task —— View job PR Review AnalysisAnalyzing this diagnostic PR for issue #1054... Todo List:
Root Cause AnalysisProblem Being Solved: Investigating a 2-second native engine overhead in CI that doesn't reproduce locally (flat 2307ms vs 7ms). Issue #1054 shows backfill behavior explains part of the problem but not this specific overhead. Why This Approach: Adding per-iteration phase breakdown to identify which specific build stage consumes the 2 seconds - parseMs, edgesMs, rolesMs, etc. This is a legitimate diagnostic strategy to pinpoint the bottleneck before implementing a fix. Risk Assessment: ✅ LOW RISK - This is a proper throwaway diagnostic branch with clear intention not to merge. The trace output goes to stderr only and doesn't affect the JSON benchmark results that CI consumes. Backlog Compliance
Code Quality AssessmentStrengths:
Technical Details:
Minor Observations:
Critical ConcernsNone identified. This is a well-executed diagnostic approach for a specific CI performance issue. Final Recommendation
Approval Conditions:
Recommended Next Steps:
|
Greptile SummaryThis throwaway diagnostic branch adds a Confidence Score: 5/5PR is explicitly marked DO NOT MERGE; changes are safe and isolated to stderr diagnostics only. No functional changes to benchmark output, no P0/P1 issues, all trace output goes to stderr and doesn't affect the JSON the gate consumes. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[buildGraph call] --> B[capture elapsed]
B --> C[push to timing array]
B --> D[logTrace to stderr]
D --> E["[1054-trace] engine.scenario[i] total=Xms phase=Y..."]
C --> F[median / result JSON to stdout]
E --> G[CI log — grep for 1054-trace]
Reviews (3): Last reviewed commit: "Merge branch 'main' into chore/issue-105..." | Re-trigger Greptile |
Codegraph Impact Analysis2 functions changed → 2 callers affected across 2 files
|
|
Thanks for the review. Acknowledged the minor observations:
No code changes needed. The branch will be closed without merging once the CI gate log gives us the phase breakdown we need to open the focused fix PR. |
|
Closing unmerged in favor of #1064, which is the actual fix for #1054. This branch was created as a diagnostic timing-trace harness to investigate why native incremental no-op rebuilds were ~2s in CI. The investigation produced the JS-side fast-skip implemented in #1064 (now ready to merge). The per-iteration phase tracing here was a one-shot diagnostic tool and is no longer needed. Branch will not be deleted in case the trace harness is useful for future investigations. |
1 participant
Purpose
Throwaway diagnostic branch. Do not merge.
The pre-publish gate shows a flat ~2-second-per-call native overhead in CI that doesn't reproduce locally on Windows or in Docker Linux. The .tf drops (#1054) explain part of the picture but not this — even with backfill firing locally, no-op rebuild is ~7ms; in CI it's 2307ms.
This branch adds per-iteration phase breakdown to `benchmark.ts` and `incremental-benchmark.ts`. Every full / no-op / 1-file iteration prints a line like:
```
[1054-trace] native.noop[0] total=2307ms setup=? collect=? detect=? parse=? insert=? resolve=? edges=? structure=? roles=? ast=? complexity=? cfg=? dataflow=? finalize=?
```
When the gate runs against this branch, the log will show which specific stage (or stages) eats the 2 seconds — `parseMs`, `edgesMs`, `rolesMs`, `structureMs`, etc. That'll tell us where to dig next.
Plan
Why diagnostic prints don't go to main
The trace lines go to stderr only and don't affect the JSON the gate consumes, so the gate's regression-guard verdict is unchanged. But committing diagnostic prints to mainline benchmarks pollutes future runs and obscures real signal. Hence the throwaway-branch shape.
Refs #1054