suite: parse phase is superlinear, making `t27c suite` unrunnable on specs/scratch (12.4M lines)

[gHashTag]

t27c suite --repo-root . cannot complete on a clean checkout. Phase 1 (Parse) stalls on the large generated wave-loop benchmark specs under specs/scratch/.

Not a regression — reproduced identically on the pre-#1775 compiler and on current master.

Measured parse scaling

lines	parse time
3,114	0.23s
4,629	0.55s
9,237	1.18s

Roughly quadratic: ~3x the lines costs ~5x the time.

Consequence

specs/scratch/ holds 329 specs totalling 12,364,121 lines. The largest:

lines	file
1,179,669	w584_bench_17d_aos_call_dedup.t27
786,483	w590_bench_module_17d_aos_var_call_reassign.t27
786,479	w591_bench_module_17d_aos_var_literal_reassign.t27
589,845	w582_bench_16d_aos_call_dedup.t27
491,567	w593_bench_module_5x2p15_aos_var_call_write.t27

Extrapolating the quadratic fit, w584 alone is on the order of hours for a single parse. Observed directly: w593 (491,567 lines) ran >30s without finishing; w595 (221,223 lines) ran >60s without finishing.

The suite spawns one t27c parse subprocess per file, so a full run is effectively unbounded. --fast does not help — its help text notes parse/typecheck/gen still run.

Impact

Contributors cannot use ./scripts/tri test or t27c suite as the documented local CI-like gate (CLAUDE.md section 2). Work has to fall back to partial verification.

Workaround in use

Running the suite against a mirror of the repo root whose specs/ omits scratch/ completes in minutes over the remaining 560 specs and exercises every phase (parse, typecheck, GF16, gen zig/rust/verilog/C, yosys smoke, FPGA smoke, seal, fixed-point).

Possible directions

• Profile the parser for the quadratic factor — likely a repeated linear scan over accumulated state per declaration.
• And/or give suite a flag to exclude specs/scratch/ (or sample it), so the default local run is usable.

Aside

That same filtered run reports 8 pre-existing gen-verilog-yosys-smoke failures on current master (e.g. igla/race/backend.t27, igla/race/rtl.t27, igla/coder/weights.t27). Unrelated to parse; filing here only so they are on record.

[gHashTag]

The quadratic conclusion does not reproduce; the sample was heterogeneous

Measured on current master (dev profile, 2 vCPU). Three independent synthetic growth axes, 7 points each, 3 repeats, minimum taken:

axis	what grows	exponent alpha in t ~ n^alpha
declarations	number of top-level fn decls	0.993
flat literal	length of one flat array literal	0.946
statements	statements in one body	0.972

All linear. Then the same question asked of the primary data — this corpus, not synthetic input. Taking one homogeneous family, wNNN_bench_module_NNx2p6_aos_var_call_write, 39 specs spanning 342 KB … 818 KB:

alpha = 0.9404   R2 = 0.9856   n = 39
cost per KB: 8.23 .. 9.10 ms   (spread 10.65%)

Cost per kilobyte is flat across a 2.4x size range, and in the wider run it drifts slightly downward with size (14.65 → 15.10 ms/KB over 342 → 818 KB in an earlier pass under different machine load). That is linear scaling.

Where the 3x-lines / 5x-time observation comes from

The three specs in the issue (3 114 / 4 629 / 9 237 lines) are from three different families, and per-byte cost is a property of spec shape, not spec size. In one run:

family	ms per KB
w574_bench_8d_aos_call_dedup	2.20
wNNN_bench_module_NNx2p6_aos_var_call_write	14.7

A 6.7x difference in unit cost between neighbouring families. Sorting a heterogeneous corpus by size and fitting a curve measures how the composition of the sample changes with size, not how the parser scales. Formally: with classes C_i of unit cost c_i and sample shares p_i(n), the observed unit cost is sum p_i(n) c_i, which moves with n whenever p_i correlates with n — and it does, because larger files come from different generators — even when every c_i is constant.

This is the confound #2133 already named for the ratchet ("a ratchet over a heterogeneous population is partly a composition metric"), reappearing in a different instrument.

The extrapolation, tested directly

The issue extrapolates w584 to "on the order of hours". Test on w593 (491 567 lines, 36.8 MB): it reaches line 491 518 — 49 lines from the end — in 4 seconds, then stops with

Error: Parse error: parse error at module level near line 491518:
Unexpected token in expression: Semicolon (';') at line 491518:6

So the largest specs are not slow. They contain a syntax error near the end that I do not find filed anywhere; that is a separate defect and probably the real reason t27c suite looks stuck rather than the parse cost.

Self-criticism: I made the same mistake in this session, an hour after naming it

Mid-session I fitted ms/KB = 4.124 + 1.927 * depth (R2 = 0.9797) on a nesting-depth control series, and registered the prediction before measuring: w593 should take 1316 s. It took 4 s. Wrong by ~300x. The model was fitted inside one input class and extrapolated across classes — the identical error. Registering the prediction in advance is the only reason it became a result instead of an unnoticed mistake.

Proposed disposition

The parse phase is linear, so the --exclude specs/scratch direction in this issue stands on the corpus being large, not on the parser being superlinear. Two concrete items, both narrower than the current title:

1. the w5xx/w6xx scratch specs carrying a syntax error near EOF — worth its own issue;
2. the 6.7x unit-cost gap between spec families — a real profiling target, and not yet explained. Not investigated here.

tri cost <glob> in #2151 reproduces every number above and prints the per-KB spread next to the exponent, so a heterogeneous sample announces itself.

Measured on a dev build. Exponents and ratios transfer to release; absolute milliseconds do not.