perf: cut Optical Detector regex cost (COBOL Cartography is 76s CPU / 55% of extraction)

[squid-protocol]

Context / baseline

#3175 (largest-first worker dispatch, PR #3181) shipped output-safe but wall-flat — scheduling was never the bottleneck. A full profiled scan of all_language_repo (16.53s wall, 1.22M LOC, 73.8k LOC/s) located the real limiters. This issue covers limiter #1: the Optical Detector regex phase. Sibling: the single-threaded tail (see companion issue).

Cumulative per-worker CPU by extraction phase (÷~16 cores):

Phase	CPU (Σ workers)	ms/file
5_Optical_Detector	76.0s	26.5
5.5_Security_Lens	36.1s	12.6
4_Lexical_Scan	7.4s	2.6
others (lang detect / import regex / token / aperture / disk)	~5s	—

Optical Detector is 55% of all per-file work — 2× the already-gated Security Lens. And it's composition-driven, not size-driven: 26.5 ms/file on ALR vs ~10.6 ms/file on curl, because ALR contains COBOL. The --splicing-speed tail is unambiguous:

2.68s  cobol::Cartography_Mode_A_Labels   ← single most expensive regex in the whole scan
1.60s  cobol::func_start
1.44s  typescript::Cartography_Mode_B_Braces
0.78s  cobol::safety
0.66s  cobol::fragile_debt
... 7 of the top ~15 modes are cobol::

Goal

Bring Optical Detector cumulative CPU down the way #3069 / #3072 / #3173 brought down Security Lens, starting with the hottest modes.

Seam / files

• gitgalaxy/core/detector.py — splice() (~L1396) runs the modes; the cache-fill deriving (rule_name, pattern, mapped_key, gate, line_gate) (~L2653) is where gates attach.
• gitgalaxy/core/rule_prefilter.py — derive_literal_gate (perf: the remaining speed residuals are structural — optimize the shared coding_analysis rule pass, not individual repos #3069, required-literal prefilter), pattern_is_line_local / build_line_gate / line_gated_finditer (perf: per-line gating for the line-anchored rules the literal prefilter can't touch #3072, per-line candidate scan), prefer_selective policy (perf: Security_Lens is ~30% of scan CPU and completely ungated — prefilter + de-double-sweep (est. ~10% end-to-end) #3173).
• Cartography mode regexes: gitgalaxy/standards/language_standards/languages/*.py (per-language); labels surface in the --splicing-speed chart.

Plan

1. Profile-confirm the hot modes per language (COBOL Cartography_Mode_A_Labels, func_start; TS Cartography_Mode_B_Braces) via --splicing-speed on ALR and a COBOL-heavy repo.
2. Per hot mode, run pattern_is_line_local: if line-local, opt it into _line_gates and attach build_line_gate (the perf: per-line gating for the line-anchored rules the literal prefilter can't touch #3072 path); if not line-local but literal-anchorable, attach derive_literal_gate(prefer_selective=True) (the perf: Security_Lens is ~30% of scan CPU and completely ungated — prefilter + de-double-sweep (est. ~10% end-to-end) #3173 path).
3. For modes that resist gating (note: func_start was previously found "unwinnable"), evaluate regex rewrite / anchoring / removing catastrophic alternations, or a cheap pre-scan literal reject.
4. Correctness guard: a registry property test (mirror tests/.../test_line_gates.py) proving the gated finditer returns the identical match set as ungated for every opted-in rule.

Checklist

• --splicing-speed tail captured for ALR + a COBOL-heavy repo; hot modes ranked.
• pattern_is_line_local verdict recorded per hot mode.
• COBOL Cartography_Mode_A_Labels gated (line or literal) OR rewrite justified.
• COBOL func_start re-evaluated (prior "unwinnable" — confirm or beat).
• TS Cartography_Mode_B_Braces gated/optimized.
• Property test proves identical match sets for every newly gated rule.
• A/B (phase_ab.py --rounds 3 --control, curl + ALR) shows Optical Detector CPU ↓ with audit.json + sarif.json byte-identical.
• Golden crucible green both legs.

Verification methodology

tests/tools/phase_ab.py --repo <repo> --rounds 3 --control --engine main=<origin/main> --engine mine=<change> on curl + all_language_repo. Env: GITGALAXY_LICENSE_KEY=COMMUNITY_FREE_TIER, PYTHONPATH, KEYWORD_ROSETTA_PATH + LANGUAGE_CRUCIBLE_PATH, Bash sandbox OFF, v6/.venv python. The harness proves audit/sarif identity; the A-vs-A control separates real deltas from hash-seed noise. Judge cumulative per-worker CPU (--file-speed chart), not wall.

Lineage: builds on the prefilter/gate work in #3069 / #3072 / #3173; baseline established alongside #3175 / #3181.

🤖 Generated with Claude Code

[squid-protocol]

Sibling issue for the single-threaded post-extraction tail (limiter #2 from the same profile): #3183.

[squid-protocol]

Profiling findings (2026-09-18) — the gate approach doesn't apply to the real hot path

Measured the COBOL cost structure directly. Two corrections to this issue's plan:

1. func_start is structurally ungate-able. Tested the actual compiled COBOL rules against the prefilter machinery:

rule	line-local?	derive_literal_gate	build_line_gate
func_start	no	None	None
safety	no	✅ 6 lits	None
safety_bypasses	no	✅ 8 lits	None
args	no	✅ 2 lits	None

func_start has no required literal — it anchors on column position + any identifier (a paragraph name), so there's nothing for a #3069 segment gate or a #3072 line gate to key on, and it isn't line-local. This confirms the earlier "func_start unwinnable" note. The other rules (safety/args) already have working segment gates, so they aren't the easy win either.

2. The dominant real cost is that same ungate-able func_start regex, in two places. The trustworthy --splicing-speed chart (measured in the real parallel run, not cProfile):

2.68s  cobol::Cartography_Mode_A_Labels   → _slice_by_labels()  (also runs func_start.finditer)
1.60s  cobol::func_start                  → the ungate-able rule above
1.44s  typescript::Cartography_Mode_B_Braces

So the Optical Detector's COBOL tax is concentrated in one structural regex that can't be literal-gated. Remaining levers: a parity-critical regex rewrite of func_start, or trimming the _slice_by_labels per-function Python loop.

cProfile caveat (learned the hard way): cProfile pointed hard at _is_orphan (~20% of a COBOL scan) — a real O(functions × filesize) quadratic for hyphenated names. I fixed it (PR #3184, parity-proven byte-identical on 11,530 + 43,084 functions), but the real-harness A/B is flat — cProfile over-weights it ~50× because the cost is C-level regex. Landing #3184 as a latent-quadratic bound (helps a large single COBOL file), not a corpus speedup.

Recommendation: the ROI here is lower than the issue assumed — the addressable Optical Detector cost is one ungate-able regex. Suggest either scoping #3182 down to the func_start regex rewrite (high risk, needs exhaustive match-set proof) / _slice_by_labels loop, or parking it and prioritizing #3183 (the serial tail — mechanical, lower-risk wins). Deferring the decision.

[squid-protocol]

Parked (2026-09-18). Deprioritized per the profiling above: the addressable Optical Detector cost is concentrated in func_start, which is structurally ungate-able, so the remaining levers (a parity-critical func_start regex rewrite, or trimming the _slice_by_labels per-function loop) are higher-risk / lower-ROI than this issue assumed. Not wontfix — revisit if the fleet scan-rate-vs-size line-fit specifically implicates COBOL-heavy repos.

PR #3184 (the _is_orphan hyphenated-name fast path) stands alone as an optional latent-quadratic robustness bound — parity-proven byte-identical, corpus-flat — and can be merged or held independently of this parked regex work.

Effort moving to the sibling #3183 (serial post-extraction tail: file_data executemany + concurrent recorders — mechanical, lower-risk, targets single-threaded wall that grows with repo size).

[squid-protocol]

Fleet telemetry (v2.9.0 batch, first 22 repos): Cartography_Mode_B_Braces is the #1 CPU rule in every language composition measured — 8/8 repos across c, cpp, javascript, typescript, rust, objective-c, swift (e.g. c:: 40.4s + cpp:: 17.0s fleet CPU, 3.5× the next rule). The braces-slicer family is a cross-language hot path, not a TS/COBOL quirk — strengthens the case for a structural fix in the shared slicer over per-language gates. Data: aggregate_fleet_timing.py over gitgalaxy-raw-output/v2.9.0 (population-analyses #13).

[squid-protocol]

Full-fleet telemetry (v2.9.0, 739 repos, 280M LOC) — this is limiter #1, not deferrable

The original profile was one dev-box scan (ALR/curl). The full-fleet numbers confirm and sharpen it:

• Optical Detector = 61.2% of ALL fleet worker CPU (15,408s of 25,193s). Security Lens is a distant Bump actions/checkout from 4 to 6 #2 at 26.5%.
• Cartography_Mode_* = 55% of all rule CPU; B_Braces alone = 53% (3,931s of 7,458s across 662 rules). Top 5 rules of 662 = 50% of rule CPU.

The single highest-ROI fix on the whole board: csharp::B_Braces backtracking, concentrated in roslyn

• roslyn alone spends 1,971s in csharp::Cartography_Mode_B_Braces — ~8% of the entire fleet's CPU in one rule on one repo, and 77% of roslyn's whole scan.
• Per-MLOC cost is wildly non-linear within C#: roslyn 368 s/MLOC, runtime 40, selenium 1.0. A 368× spread inside one language is catastrophic backtracking, not brace density — almost certainly roslyn's deeply-nested generics / expression-trees hitting a nested-quantifier {…} matcher.

The issue's COBOL Cartography_Mode_A_Labels is real but a smaller, corpus-specific slice; fleet-wide the hot mode is B_Braces across the C-family, led by C#.

Recommendation: un-defer. This is the top perf priority by a wide margin. Suggested first step (single-file reproducible, ~1,971s of headroom on roslyn): profile csharp::B_Braces on roslyn's worst files, find the trigger construct, fix the backtracking. Happy to spin that out as a focused child issue if you'd prefer it tracked separately from the structural-slicer rewrite.

[squid-protocol]

PR #3317: the roslyn csharp::B_Braces hotspot was csharp func_start Branch C's lookahead, polynomial in whitespace. String literals are blanked to whitespace in the safe stream, so VerifyIL("...", @"<8KB IL>") calls cost ~10s each, tripping the 60s fuse; the swallowed TimeoutError then shipped those files with 0 functions. It's rewritten as the same language, linearly. roslyn: wall 289→98s, Optical 2,555→472s, B_Braces 1,958→75s; 22 files recovered (+2,474 functions), no losses, match-set parity on 23k C# files.

Remaining (see PR): ambiguous [...] tokenization (attribute shield vs char-class vs bracket-alt) still fuses one roslyn file and makes stacked [InlineData] blocks slow. A non-language-preserving fix needs a parity-policy decision (atomic groups are unavailable at py3.9).

🤖 Generated with Claude Code