Measure what the slow floor witnesses actually cost, before any are pared

[briansrls]

gunbc#8455 established that the floor's per-row wall time is not always the row's cost, and named the repair it did not perform — attribute shared cost to the entry rather than its first row. This is that repair, plus the mechanism root-caused to source.

The mechanism, named

The floor builds a fresh evaluation frame per claim, so the sharing #8455 measured is not an eval memo — a per-claim memo cannot survive between claims. It is the seed's process-global corpus-scan caches, each filled at most once per process and read free thereafter.

The #8455 specimen resolves exactly. g2_data_reference_under_selection's specimen_projection reaches v2.lens.live_read_classification live_read_selection_manifest_live → dependency_resolution_facts_live, whose seed realization cli_run.rs reference_resolution_facts performs "one O(corpus) parse pass over the pool, cached" behind REFERENCE_EDGE_CACHE. The first claim pays the pass (12197ms); the second reads the map (31ms). Same call, 393x, 35ms apart.

Why the existing number cannot answer the paring question

Nothing is computed twice — the caches are correct, and the sharing is the saving. What is wrong is the attribution, in the direction that decides things, because the ceiling refuses per row:

• a refusal names the first toucher, whose own cost may be milliseconds;
• splitting such a row moves the charge to whichever fragment runs first (witness_decomposition_does_not_reduce_entry_cost_note, observed rather than predicted);
• removing such a row does not remove its cost either — the next claim to touch the fill pays the same seconds.

What lands

cli_run/shared_fill.rs records, per fill: the cache, the key it is declared on, what the fill cost, which claim paid it, and every later claim and module that read it. Eleven caches instrumented — reference_edges, module_graph_facts, module_path_index, and the eight whole-corpus census reports.

gunbc.witness_row_cost owns the model: SharedFillPayer, and a three-state SharedFillDisposition because there are three remedies — outside-fold (preparation's cost, which no witness can be pared to recover), exclusive (one module owns it and loses it with itself), shared (survives any single removal). Collapsing the first into either of the others is how a removal comes to be justified by a saving it cannot deliver.

gunbc.observation_ci_render owns the line; the seed mirrors it and both sides assert one literal, so a format drift reds one of the pair rather than forking silently.

The quantity a removal decision needs, joined against the [floor-witness-slow] rows the floor already prints:

what removing module M saves = M's rows' wall time
                             - fills M paid that are `shared`
                             (+ nothing at all for `outside-fold` fills)

What this is not

It refuses nothing, skips nothing and changes no verdict; it prints a table (DESIGN §5's sanctioned stopped-line audit — it reports, it does not green). It makes no witness faster and takes no position on which rows should be pared. unattributed_hits states the shared figure as a lower bound: reads served by a fill this ledger did not observe.

Receipt — run 32192150969, 9425 claims, 19 fills

The run is main's inherited red (failed=0 stale_quarantine=5 budget_refused=102), not this diff's; the fold completed and the ledger reported.

One row's entire cost is a fill 29 other modules read. module_path_index key=dag+src/v2, fill_ms=51508, paid by dissolution_census_witness_test.unbound_dissolution_empty_literal_refuses and read by 139 claims across 29 modules. That payer is one of five rows in the corpus with an exact cost — 51620ms — so 99.8% of its measured cost is a computation 29 other modules consume. It is the run's only shared fill. Removing that witness recovers ~112ms and hands 51.5s to whichever of the other 29 goes first.

And the opposite, one row away on the same list. The 86741ms red_seed_runner_failure_detail_projects_located_receipt paid a 29017ms module_graph_facts fill and a 24965ms reference_edges fill, both exclusive — nobody else reads either. Its cost is genuinely its own and it is a real paring target. Nothing in the per-row wall time distinguishes the two cases.

~108s is outside-fold — paid before any claim ran. Quarantining every witness on the floor would not move it.

The prediction, confirmed on an experiment nobody had to build (measured by tidy-lark-471): across #8457's quarantine, in one module and one run, single_refinement_carrier_emits_no_unsupported_cast went 746ms → 45941ms while its sibling stayed flat at 763ms. The fill its neighbour used to pay re-landed on it; the sibling rides it free in both eras. Quarantining a first toucher relocates the bill.

Second receipt — run 32196069889: the same fill changing hands

The first receipt reported consumer counts; this one names them, and caught the same fill change payers.

run 32192150969   module_path_index  dag+src/v2   fill_ms=51508
                  paid_by  dissolution_census…unbound_dissolution_empty_literal_refuses
                  read by  139 claims / 29 modules        shared

run 32196069889   module_path_index  dag+src/v2   fill_ms=45075
                  paid_by  emitter_nested_refinement_cast…single_refinement_carrier
                  read by   94 claims / 20 modules        shared

Same cache, same key, paid_by changing hands after #8457 quarantined the first payer. The second payer is main's only failing witness. On this run it measured 45784ms, of which 45075ms is this fill — ~98.5%, and that share is pinned to the run: the same row measured 45784, 45941, 46714, 50532 and 52982 across five runs the same day, so the fill fraction is robust and the denominator is not. Nearly all of the remaining red is one build that 20 other modules read for free.

The consumer set also shrank across the quarantine — 139 claims / 29 modules → 94 / 20. A consumer is a free rider: it reads a fill someone else built, so its marginal cost for that fill is ~zero. Quarantining a rider removes coverage and recovers nothing on this axis; quarantining the payer is what produced the red. (The first receipt had counts only, so those nine modules cannot be named retroactively — which is exactly why the line now names them.) The riders are named, so the next hop is a prediction rather than a warning: evaluation order is alphabetical, so quarantining this payer hands ~45s to emitter_optional_payload_cast_witness_test. The fix is #8470, which pays this index in preparation; I reviewed it rather than writing a second one.

A correction to this instrument, from its own first receipt. The reported TOTAL fill_ms=302362 was an inclusive sum: these caches compose, so a module-graph fill contains the path-index and reference-edge fills it triggers — visible in the receipt's own rows, 17890 = 12054 + 5141 + ~695. Fills now carry self and inclusive separately, the total sums self (~180s), and a planted two-level test pins the arithmetic. The payer/consumer/disposition columns were never affected. Two bounds on reading them, both from measurements handed over today and recorded in the design note: run-to-run variance is ~18% for a near-ceiling row on byte-identical input (sharp-raven-273), and 84 of main's 97 budget-refused rows are pinned at their interrupt point and carry no cost to decompose (tidy-lark-471, correcting an earlier reading).

Coordinated with tidy-lark-471, sharp-raven-273, and #8455/#8457.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BXMNpLmt4mGzThb7pfHVJS