Measure where HermitCrab's time actually goes, across 33 grammars

[johnml1135]

HermitCrab has been optimised repeatedly without anyone measuring where its time goes. This branch measures it — across 33 grammars rather than three — and the answer redirects what we should build next.

What it adds. A wall-time split of ParseWord into eight exclusive buckets that sum to wall (analysis total, analysis cascade / battery / phonology, lexical lookup, synthesis cascade / battery / forward, ExpandAlternatives), a die-point histogram for rejected synthesis candidates, and a fold-step sharing census. All behind one volatile bool, false in normal operation; every edit is an insertion before an existing return or continue. No behaviour change: 582 passed / 1 skipped / 0 failed, including every conformance fixture gate.

Where the time is. Not synthesis. Synthesis is ~5% of Sena and 0.3% of Amharic. The cost is analysis, and which part differs by grammar: Sena is affix-template-battery-bound (51.4%, still, after the memo that bought 5x) plus ExpandAlternatives at 20.3% — a bucket nothing had ever instrumented. Amharic is cascade-bound (~95%), at ~170 ms per analysis state in a cascade already at its state-count floor.

The finding that closes a family. Forward synthesis is a deterministic trail-driven fold, and the sharing looked large: 3.22x and 8.10x, ~50% wall ceilings on the two fixtures big enough to time reliably, reproduced across two independent runs. It was built (stacked branch, parity clean, 0 divergences on all 33 fixtures) and it does not pay — hits = 0 on the best fixture, 0.96x, i.e. 4% slower from key construction alone. A sound key must carry the ordered remaining trail, and two candidates then have to agree on their whole future to share a step.

That is the third independent route to the same result. The redundancy is apparent, not real: the trail is what makes each step distinct, and every measurement showing large shareable work is measuring a key that omits it. Packed forests, fold sharing and synthesis-input dedupe all need distinct derivations to converge on a genuinely identical state; in this engine they do not.

What to review. docs/hermitcrab-optimization-ledger.md is the deliverable — 20 rows, tried / closed / open, with the number that settled each. The instrumentation is mechanical; the judgement is in the ledger.

Note on process: the research docs are deliberately kept in-repo, not evicted into accordions. Three of these avenues have already been independently rediscovered and re-retracted — the 9,774x dedupe figure has been re-derived twice by different routes. A closed avenue is only closed if the next person finds out cheaply that it is closed.

Category results — every group at the 2x bar

Ratios are deterministic and reproduce byte-identically across runs. Only wallMs >= 50 rows can carry a timing claim: one 10 ms fixture's share moved 1.3% to 14.5% between two runs of identical code.

group	fixtures at >=2x	verdict
A. Affix template slots	5 of 6 — 8.10x, 3.22x, 3.00x, 2.81x, 2.15x	Clears; both reliable rows live here
B. Disjunctive allomorphs / free fluctuation	2 of 2 — 3.00x, 2.00x	Clears on mechanism; sub-4 ms fixtures
C. NaturalClass precision	1 of 1 — 3.94x	Clears on mechanism; 10 ms fixture
D. Stem names	1 of 1 — 2.00x	Clears on mechanism; 2 ms fixture
E. Subrule gating	2.00x from 2 applications	Discarded — one observation
F. Compounding	none — 1.48x, 1.00x	Fails
G. MPR features/groups	none — 1.17x, 1.00x	Fails; the order-dependent fixture is exactly 1.00x
H. Metathesis / truncation / in-place modification	none — 1.11x, 1.00x, 1.00x	Fails, as the mechanism predicts
I. Phonological rewrite direction / iterative	none — 1.50x, 0 apps	Fails / no signal
J. Loader and character-table edge cases	none — mostly 0 apps	No signal; no rule application
K. Feature-system breadth	none — 1.60x, 1.58x, 1.00x	Fails, clustered just under

The categories are real — A and B have a clean mechanistic reason to share, and the fixture built to be order-dependent reports exactly 1.00x, which is the mechanism failing where it should. The 2x was real as available sharing. It is not extractable, because what makes it visible is what makes it unsound.

F through K are retained rather than deleted: they are the reference for judging a future grammar, and a category that fails on today's fixtures may pass on a grammar we do not yet have.

Corrections made during this work

Three findings were published inside this branch and then withdrawn on measurement. All three were arithmetic on an unmeasured denominator.

1. "Synthesis is the bottleneck." Built on candidate counts — 218,847 synthesis inputs on one Sena word returning 0 parses. Those candidates cost ~0.5 us each. Counting volume is not counting time.
2. "Amharic is synthesis-bound." Inferred as ~160 ms per synthesis run by dividing 30 s by 186 inputs. Its forward synthesis is 14 ms; the 36 s is the analysis cascade.
3. "Fixtures only look synthesis-heavy because they are small." Cited the largest fixture as having the lowest synthesis share, 6.1%. That was synForward, which is explicitly net of the cascade and battery buckets while the shared work runs inside them. Its real share is 73.9% — the highest of any reliable row. The trend the argument rested on does not exist.

A fourth was caught in the harness rather than published: a first A/B design showed 1.53x purely from JIT warm-up, with the off-arm varying 42.7% between its own first and second sample. The harness now discards warm-up, takes min of N interleaved samples per arm, and prints the off-arm spread beside every speedup.

The wall-time split this branch adds is what makes all of these checkable. It was a required row in a predecessor plan and was skipped.

Durable constraints, and the retained classifier

Two findings are in-repo because the code cannot express them:

• Word.ReplayOnto does not splice _mrulesUnapplied. Safe only because AnalysisStateKey includes the per-rule count multiset, which guarantees arrival and stored-arrival counts match on a hit. Anyone narrowing that key breaks this silently. Fix if needed: store arrival counts on MemoEntry and compute stored - storedArrival + query.
• HermitCrab's morphological rules are not order-invariant. Same pending-rule multiset, different application order, different synthesis output. This bounds every packed-readout scheme, and it is the assumption Maxwell and Kaplan (CL 19(4):571-590) rely on and HermitCrab does not satisfy.

RuleLengthClassifier is retained with 12 tests and no callers. It encodes a direction trap that is easy to get backwards: on the analysis side rules are un-applied, so a rule that inserts on synthesis removes on analysis, and one that truncates on synthesis untruncates — an Lhs part with no Rhs copy makes the un-applied word grow. AnalysisMorphologicalTransform.GenerateShape is the authority. Removing it is defensible; keeping it means the next attempt at length-based pruning will not get the sign wrong.

Commit 1a7d484c bundles two concerns — a harness reporting change and a docs analysis — because the change was swept in from an uncommitted state. Noted rather than rewritten.

Next: per-node cost

Every optimization in the ledger that worked reduced how many nodes are visited. None touched what a node costs. Amharic spends ~170 ms per analysis state in a cascade already at its state floor — the state count is a floor, and the cost per state is unexplored. That decomposition (FSA pattern matching vs feature unification vs clone/freeze vs key hashing) is the next probe, and it is in flight.

---

This change is 

[johnml1135]

Superseded by #490 (docs-only). Instrumentation stays on feature/synthesis-fold-probes and feature/per-node-cost; the ledger names which branch holds what. The probes gate on volatile bool reads inside Matcher.cs, a hot inner loop in SIL.Machine — acceptable for a measurement run, not something to carry in the tree. The five working docs are also not merged: they contain retracted intermediate claims that would sit in the tree next to the corrected numbers.