docs: update build performance benchmarks (3.1.3)

[github-actions]

Automated build benchmark update for 3.1.3 from workflow run #286.

[greptile-apps]

Greptile Summary

This is an automated documentation-only PR that records 3.1.3 build benchmark results, generated by the CI workflow after measuring codegraph running against its own codebase (236 files). Both README.md and generated/benchmarks/BUILD-BENCHMARKS.md are updated consistently, and all top-level metrics cross-check correctly against the detailed data and the embedded JSON block.

Key highlights for 3.1.3 vs 3.1.2:

• Native build speed improved slightly: 5.2 → 5.1 ms/file
• WASM build speed improved: 15 → 14.6 ms/file
• 1-file native rebuild improved: 296 → 282 ms (↓5%)
• WASM Complexity phase anomaly: jumped from 5.3 ms → 72.6 ms (≈13.7×) in the full build and 0.5 → 3 ms in the 1-file rebuild, while native complexity was flat — this polarity flip is masked by the overall WASM build time improving and may be worth a closer look before 3.1.3 numbers are treated as a stable baseline

Confidence Score: 4/5

• Safe to merge — purely automated documentation update with no code changes; one data anomaly is worth investigating but does not block the PR.
• All benchmark values are internally consistent between README.md, the markdown tables, and the embedded JSON. The only concern is a large WASM complexity phase spike (5.3 ms → 72.6 ms) that is masked by overall build time improving — this is a data observation rather than a merge blocker for a docs-only PR.
• generated/benchmarks/BUILD-BENCHMARKS.md — specifically the Build Phase Breakdown table, WASM Complexity row (line 73)

Important Files Changed

Filename	Overview
generated/benchmarks/BUILD-BENCHMARKS.md	Adds 3.1.3 benchmark rows (native + WASM) across all sections — version table, raw totals, phase breakdown, incremental rebuilds, query benchmarks, and embedded JSON. Data is internally consistent, but the WASM Complexity phase shows a notable 13.7× spike (5.3 ms → 72.6 ms) worth investigating.
README.md	Updates the top-level performance summary table with 3.1.3 values (build speed, rebuild time, query times, 50 K estimate). All values cross-check correctly against the detailed benchmark file.

Sequence Diagram

sequenceDiagram
    participant WF as CI Workflow #286
    participant CG as codegraph (self)
    participant DB as SQLite DB
    participant BM as BUILD-BENCHMARKS.md
    participant RM as README.md

    WF->>CG: Run full build (native + WASM) on own codebase
    CG->>DB: Parse 236 files, store nodes/edges
    CG-->>WF: Emit timing metrics per phase
    WF->>WF: Compute per-file averages & % deltas vs 3.1.2
    WF->>BM: Prepend 3.1.3 rows (version table, phase breakdown, incremental, queries)
    WF->>BM: Append 3.1.3 JSON block to BENCHMARK_DATA
    WF->>RM: Update summary table with latest 3.1.3 values
    WF->>WF: Open PR #423 via github-actions[bot]

Loading

_{Last reviewed commit: 92c35ea}

[greptile-apps]

WASM complexity phase spike warrants investigation

The WASM Complexity phase shows a dramatic increase from 5.3 ms → 72.6 ms (≈13.7× slower) compared to 3.1.2, while the native Complexity phase barely changed (13.1 ms → 12.6 ms). The WASM 1-file rebuild complexity also regressed from 0.5 ms → 3 ms (6×).

Prior to 3.1.3, native was ~2.5× slower than WASM for this phase — now WASM is ~5.8× slower than native. That polarity flip is unusual for a compute-intensive phase and may indicate:

• A code path change in 3.1.3 that exercises a WASM-unfriendly pattern (e.g., heavy cross-function calls, tight loops over large data structures)
• A cold-cache anomaly specific to the WASM JIT for this run

The overall WASM build time still improved (3.5 s → 3.4 s) because savings in other phases compensated, so this regression is masked at the top-level. If this wasn't intentional it may be worth investigating the complexity pass in the WASM engine for 3.1.3 before the numbers are taken as the new baseline.