Archive — history, not state. Kept for its reasoning and its evidence; its plan is closed.

Compiler switch report — what each switch changes on a real artifact

Measured 2026-08-05 (night of 2026-08-04) on branch cp/switch-report, base commit 1d65dd7da10a640b17f8017623904795f212ae89 (lane/cp, “Merge p/dedup-census into lane/cp”). Every number below comes from runs made tonight in the worktree .claude/worktrees/night-switchreport; nothing is quoted from plans/one-binary.md or plans/compiler-perf.md.

1. The artifact

The pit-shop/clerk linked closure — the P7 census corpus.

The 99 locators came from the shop itself:

./pit compile linked_plan pit-shop/clerk.ce      # module_count: 99

and were mapped to the 99 source files listed in plans/night-2026-08-04/corpus.txt (locator pkg/mod → pkg/mod.cm|.ce). P7 recorded 4,188 functions against 4,195 here; the seven-function drift is ordinary source movement between that census and this tip.

2. Method

The matrix is not run through the shop. A shop realization bakes one compiler profile into the derivation key, so switching passes per row would have measured cache behaviour rather than compiler behaviour. Instead a single harness actor compiles all 99 sources itself, once per row, with the switch record handed straight to streamline:

compiler.mcode_unit_result(src, path, {
  link_mode: "pool",
  streamline_options: {profile: <name>, stage: "unit", passes: {...}}
})

The harness is committed beside this report as plans/night-2026-08-04/switchbench.ce. Reproduce a row with:

cd <worktree>
make                                     # once
echo <config-name> > $SCRATCH/config.txt
cp plans/night-2026-08-04/corpus.txt $SCRATCH/paths.txt
./pit $SCRATCH/switchbench.ce            # writes $SCRATCH/rows/<config>.json

(the harness has the scratch directory as a def SCR constant at the top — point it at your own).

Column definitions, all measured on the final IR:

• instructions — sum over every function of ir_stats.detailed_stats(fn).instr across all 99 units. Labels are excluded, _nop_ rows are counted. This is not the linker’s own program_code_stats counter; that one counts every row and reads ~1.34x higher (see §5).
• guards — the same walk’s .guard count (the nine census guard ops). Equal, in every row, to guard_reasons.analyze’s census_sites.
• guard-reason top-5 — shop_tools/internal/guard_reasons.cm summary.census_by_reason, merged across all 99 units.
• literal-pool rows — per-module rows: sum length(unit.literals). Linked rows: the program’s stats.literal_rows_after.
• artifact bytes — shoplib::canonical.encode (binary Nota) of the portable mcode payload: per-module, the sum over the 99 pit.mcode.unit@3 records; linked, the sum over the 99 literal-stripped linked units plus the one shared literal group. This is the mcode artifact, not a pressed Mach pool and not a cart. (mach_press refuses a pool-lane unit without an import covering, so pool bytes were not available for a like-for-like row.)
• compile s / link s — time.monotonic inside the harness actor around the 99-unit compile loop and around mcode_link.link_result separately. Process startup, file reads and the census walk are outside both clocks.

Linked rows use P6’s semantic linker with the SHIP_PLAN shape from shop_tools/internal/diff_runner.cm:

{schema: "pit.mcode.link-plan@1", profile: "ship",
 granularity: "program", stripping: {names: false, logs: []}}

Import edges were wired by resolving each unit’s use() claim package-qualified (pkg::mod → pkg/mod, bare mod → <own pkg>/mod) against the 99-locator set. 238 of 373 distinct claims resolved; the remaining 135 are C natives, platform alias modules and fallback-package resolutions and were left unwired. §6 shows why that does not move the result.

3. The matrix

Baseline for the “vs ship” columns is row 2. Total s = compile + link.

Rows 5a–5e turn exactly one switch off relative to row 2; everything else in the ship profile stays on. Rows 6–7 compile every unit at stage: "unit" first (that is the compile s column) and then run the program linker over all 99 units at once (link s).

Guard-reason top-5

slot_type_unknown_at_join is the top reason in every row, at 37.0% of ship’s 112,533 census guards. Nothing in the matrix moves it more than 1.9% (row 7, −806 of 41,670), and turning type_checks off raises it by 51%.

Linker’s own counters (rows 6 and 7)

The linker reports its statistics over its own instruction walk, which counts every IR row. Recorded verbatim so this run is comparable to P7’s:

P7 recorded 1,122,900 instructions and 8,890→3,662 literal rows on this closure; tonight’s 1,128,125 and 8,549→3,544 are the same measurement on a slightly moved tree.

4. Findings

The three profiles are not three profiles. dev, ship and small produce outputs within 0.32% of each other on instructions, 1.02% on guards and 0.14% on bytes. dev — which turns off inline, licm, int_ranges, sroa, forward and switch — is worse than ship on every output axis and slower to compile (120.8 s vs 104.7 s). Whatever dev is buying, it is not compile time on this corpus; the passes it disables (forward, sroa) shrink the IR that every later pass then has to walk, so removing them costs more than they cost. small is exactly ship minus inline, and its output is byte-identical to row 5d, which is how we know the output columns carry no run-to-run noise at all.

Which switches pay:

join_types does not clear John’s bar, by a wide margin. Row 4 against row 2: −0.36% instructions, −0.23% guards, −0.30% bytes, for 209.5 s against 104.7 s — exactly 2.00x compile time. The standing ruling is that ~5% program win is worth 2x compile. This is 0.36% for 2.00x, roughly 14x short. On top of the fully linked baseline (row 7 vs row 6) it is worse still: −0.075% instructions and −0.06% bytes for +120 s. The default-off setting in pit-compiler/passflags.cm is correct as it stands, and this corpus does not support flipping it — even though slot_type_unknown_at_join is the largest guard class, join-aware facts clear only 258 of its 41,670 sites (0.62%) at the unit stage.

What link time buys, and it is the best row in the table. Row 6 against row 2, holding the unit-stage compiler identical:

• literal-pool rows 8,552 → 3,544 (−58.6%, 5,005 rows coalesced into one program group)
• artifact bytes 57,660,153 → 54,271,643 (−5.88%, 3.39 MB)
• instructions −1.54% (13,150 rows), guards −1.34% (1,508)
• cost: +67.8 s on 104.7 s, i.e. 1.65x total compile time

That is a 5.9% artifact win for 1.65x — the only lever in this report that clears the 5%-for-2x bar, and it clears it with room. Most of the byte win is the shared literal pool (5,005 rows coalesced); the link-stage streamline contributes the −1.54% instructions / −1.34% guards on top. The 67.8 s was not broken down between the two phases. Link cost is also a once-per-closure charge rather than a per-unit multiplier, so it does not tax the edit-compile loop the way join_types does.

P6’s import-edge finalization fires on nothing here, and this is not a wiring artifact. finalized_sites is 0 with 1,334 member references seen. The reason is not the 135 unwired native/alias imports: running mcode_link.export_summary directly over all 99 compiled units returns generic for 99 of 99. Zero modules in the shipped clerk closure present the shape the recognizer requires — exactly one return, of a stone(record) built with no non-construction control flow in the module body. Real modules branch while building their export record (platform selection, capability probes, memoization), which sets control_safe false and drops the candidate to generic. The size half of P6 is therefore carried entirely by the literal pool; the direct-reference half is, on this artifact, inert. If direct references are wanted, the recognizer has to be taught the branch-and-freeze shape, not merely handed a better import graph.

Compile cost, in seconds, for the record. ship compiles the 99-unit closure in ~105 s in-actor. Enabling join_types costs +105 s. Linking costs +68 s. Disabling type_checks costs +25 s (a loss on both axes). Everything else moves the clock by less than the measurement noise.

5. Caveats

1. Wall-time is noisy; output metrics are exact. Two independent runs of the identical configuration measured 104.70 s and 109.98 s for ship (+5.0%), and rows 3 and 5d — semantically the same configuration — measured 95.66 s and 111.27 s (+16.3%) while producing byte-identical outputs. Treat any compile-time delta under about ±16% as noise. Only join_types (+100%), linking (+65%) and type_checks-off (+24%) are outside that band. All output columns (instructions, guards, literal rows, artifact bytes) are deterministic — rows 3 and 5d agree to the byte on all four.
2. One sample per row. No medians. Given caveat 1 this matters only for the time column.
3. “Artifact bytes” is canonical mcode, not a cart. It is the binary Nota encoding of the portable units (plus the program literal group when linked). It is a faithful proxy for payload size and it is what the literal pool acts on, but it is not boot/root.cart bytes and it is not pressed Mach pool bytes. mach_press cannot press a link_mode: "pool" unit without an import covering (mach_pool_emit: pool-global VALUES link disrupted), so a pool-bytes column could not be made like-for-like across linked and unlinked rows.
4. Instruction counts here are lower than the linker’s. 855,147 (per-function detailed_stats) vs the linker’s 1,141,278 for the same program; the linker counts every IR row including labels. Both numbers are reported so this run can be compared either way.
5. 135 of 373 use() claims were left unwired in the linked rows (C natives, platform alias modules, fallback-package resolutions). This is a floor on import finalization — but see §4: the export recognizer rejects all 99 units regardless, so a complete graph would not have raised finalized_sites above 0.
6. Row 7 turns join_types on at the unit stage only. The link plan’s profile field is validated against dev|ship|boot only (valid_link_plan in pit-linker/mcode_link.cm), so there is no way to hand the link-stage streamline a join_types: true override without editing the linker or adding a profile. Row 7 is therefore “unit-stage join facts, then the ordinary ship program link”. The link-stage half of join_types is unmeasured.
7. The switch surface is passflags.resolve options, not the shop. No shop toggle was exercised; the derivation key still bakes one compiler_profile. Nothing here says how these switches behave through a real pit build.
8. The tree’s known linker-test disruptions were not exercised. tests/mcode_link.cm’s three disrupting tests were left alone as briefed. The linker itself did not disrupt in any row: both linked rows returned a valid pit.mcode.program@1 with zero diagnostics and all 99 units materialized.
9. Two shop-side oddities were hit while collecting the corpus and are worth someone’s time, but are not part of this report’s claims: a cache-hit ./pit compile linked_plan pit-shop/clerk.ce hung past the 600 s terminal session cap after load_cached_executable (the cold run of the same command completed in 97 s), and a make-spawned pit forge process was still holding .pit/pit.pid after make exited 0, which made the next client refuse with “shop daemon has different build signature”.

6. Raw rows

Everything this report claims is in the directory beside it:

• rows/<config>.json — the eleven matrix rows verbatim as the harness wrote them, each with the full guard-reason and guard-op histogram and (for linked rows) the linker’s own stats block.
• rows/_exportprobe.json — the export_summary census ({"generic": 99}) and the repeat ship compile used for the noise estimate in §5.
• switchbench.ce — the harness that produced every row.
• exportprobe.ce — the export_summary / repeat-compile probe.
• corpus.txt — the 99 source paths of the clerk closure, in the order compiled.

Source: plans/archive/night-2026-08-04/switch-report.md