fix(bench): use per-engine file count in benchmark reports#926
fix(bench): use per-engine file count in benchmark reports#926carlos-alm merged 3 commits intomainfrom
Conversation
|
Claude finished @carlos-alm's task —— View job Root Cause AnalysisProblem Being Solved: The native engine's
|
Greptile SummaryThis PR fixes the benchmark report so each engine (native / WASM) displays its own file count instead of always showing the WASM primary count. The two-line change in Confidence Score: 5/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[benchmark.ts worker process\neach engine: native / wasm] -->|produces workerResult\nfiles: totalFiles\nperFile: buildTimeMs / nodes / edges / dbSizeBytes| B[forkEngines collects results]
B --> C[formatEngineResult\nnow includes files: data.files]
C --> D[JSON output\nnative.files wasm.files\nboth present]
D --> E[update-benchmark-report.ts\nloads history]
E --> F{engineRow\ne.files ?? h.files}
F -->|per-engine file count| G[Markdown table row\nFiles column correct]
E --> H{Raw totals loop\ne.files ?? latest.files}
H -->|per-engine file count| I[Raw totals section\nFiles row correct]
Reviews (3): Last reviewed commit: "Merge branch 'main' into benchmark/build..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| | Version | Engine | Date | Files | Build (ms/file) | Query (ms) | Nodes/file | Edges/file | DB (bytes/file) | | ||
| |---------|--------|------|------:|----------------:|-----------:|-----------:|-----------:|----------------:| | ||
| | 3.9.3 | native | 2026-04-13 | 727 | 3.3 ↓79% | 29.5 ↑11% | 25.4 ~ | 51.6 ~ | 43981 ↑7% | |
There was a problem hiding this comment.
Files column still incorrect
The Files column for native still shows 727 (WASM's count), because formatEngineResult() in scripts/benchmark.ts (lines 40–55) still omits files from the engine result, and engineRow() in scripts/update-benchmark-report.ts (line 104) still reads h.files for both engines.
You can verify the inconsistency in this very row: 2,187ms ÷ 727 = 3.0 ms/file, not the 3.3 shown in the Build (ms/file) column. The 3.3 was computed using native's actual ~663 files (2,187 ÷ 663 ≈ 3.3). The same mismatch appears in the raw totals section where "Files: 727" is shown for native.
The fixes described in the PR summary — adding files to formatEngineResult() and using e.files ?? h.files in engineRow() and the raw totals block — are not present in this diff. Without them, the display will keep using the WASM file count for native rows.
Add `files` to formatEngineResult() so each engine preserves its own file count. Use `e.files ?? h.files` in engineRow() and raw totals for correct per-engine display with backward-compat fallback.
|
Fixed in 7f154b9:
|
Codegraph Impact Analysis2 functions changed → 2 callers affected across 2 files
|
1 participant
Summary
filesinformatEngineResult()so each engine preserves its own file counte.files ?? h.filesinengineRow()and raw totals section for correct per-engine display (with backward compat fallback for older history entries)Previously, the native engine's
Filescolumn and raw totals always showed the WASM file count (~727) instead of native's own count (~663), making per-file metrics appear inconsistent.Closes #925
Test plan
node scripts/benchmark.jsand verify the JSON output includesfilesinside bothnativeandwasmobjectsnode scripts/update-benchmark-report.jsand verify BUILD-BENCHMARKS.md shows different file counts per engine when they differfilesstill render correctly using the top-level fallback