h-dv/code-index

Watch

Fork 0

The package path costs ~8x the builtin path in SQLite work for byte-identical facts, and its vm_step is non-deterministic #113

New issue

Closed

opened 2026-09-04 15:53:26 +02:00 by buildagent · 3 comments

buildagent commented

2026-09-04 15:53:26 +02:00

Member

Two findings from #84 phase 4's cost leg (crates/indexer/tests/ruby_package_cost.rs, baseline tests/corpus/ruby-package-cost.json). Both are recorded rather than fixed. Full context: _prdoc/records/84-P4-parity-deltas.md §4.

The setup

Two legs over the SAME 156 ruby-sinatra files, both through index_path_with_packages, in one process, back to back, median of 3 warmed-up passes:

builtin leg — crates/plugins/src/ruby.rs, no packages;
package leg — the same corpus under a shadow extension, extracted by tests/packages/ruby with all six pool capabilities granted.

The two produce 1260 identical symbols, 18,450 identical ref sites and 231 identical imports. The only content differences are the five pinned deltas of #112 and #84.

Finding 1 — 8x the SQLite work for the same rows

dimension	builtin	package	ratio
`vm_step`	13,112,000	106,648,538	8.1x
`fullscan_step`	170,337	3,925,601	23.0x
`sort`	290	124	0.4x
`autoindex`	20,837	20,837	1.0x
wall clock	~0.6 s	~2.1 s	3.5x

temp.pool_admit's admission JOINs are not the explanation: PoolAdmit::prepare turns on from the SCHEMA (symbols.contribution_id + component_capabilities exist), not from whether a package is installed, so both legs carry every admission join. The cause is not yet known.

For scale: the 2026-08-29 regression that motivated corpus_cost.rs was 3.2x wall for byte-identical content, and was treated as a defect rather than blessed. corpus_cost cannot see this one — its own doc says why:

THE PLUGIN PATH, ENTIRELY. The pinned corpus installs no packages … so no repo here routes a file to a guest and this ratchet has never executed one.

Finding 2 — the package leg's `vm_step` is not deterministic

Seven consecutive medians-of-three on one box:

package vm_step   103,293,096 .. 106,648,538     3.3% spread
builtin vm_step    13,108,589 ..  13,112,703     0.04% spread
fullscan/sort/autoindex (both legs)              stable to 3 units

Single readings without the warm-up were worse: 101.5M..111.2M, 9.6%.

The content is deterministic — two package-leg indexes of the same tree produce byte-identical symbol and ref projections — so this is cost non-determinism only. corpus_cost's premise is that these counters are "properties of the STATEMENTS and the DATA, not of the machine", proven over eleven passes at 0.02%; that premise does not hold on the package path.

The direct consequence: ruby_package_cost.rs's BAND_UP_PCT is 8 rather than corpus_cost's 5, i.e. the gate can see a 10% regression in SQLite work and not a 5% one. Tightening it needs this understood first.

Also worth knowing

The blessed wall_ratio_pct (350, ceiling 525, floor 227) was measured on a box at load average 6..12 with twelve cores. It should be re-blessed on an isolated runner before it is relied on to catch anything below ~1.5x.

Two findings from #84 phase 4's cost leg (`crates/indexer/tests/ruby_package_cost.rs`, baseline `tests/corpus/ruby-package-cost.json`). Both are recorded rather than fixed. Full context: `_prdoc/records/84-P4-parity-deltas.md` §4. ## The setup Two legs over the SAME 156 `ruby-sinatra` files, both through `index_path_with_packages`, in one process, back to back, median of 3 warmed-up passes: * **builtin leg** — `crates/plugins/src/ruby.rs`, no packages; * **package leg** — the same corpus under a shadow extension, extracted by `tests/packages/ruby` with all six pool capabilities granted. The two produce **1260 identical symbols, 18,450 identical ref sites and 231 identical imports**. The only content differences are the five pinned deltas of #112 and #84. ## Finding 1 — 8x the SQLite work for the same rows | dimension | builtin | package | ratio | |---|---|---|---| | `vm_step` | 13,112,000 | 106,648,538 | **8.1x** | | `fullscan_step` | 170,337 | 3,925,601 | **23.0x** | | `sort` | 290 | 124 | 0.4x | | `autoindex` | 20,837 | 20,837 | 1.0x | | wall clock | ~0.6 s | ~2.1 s | 3.5x | `temp.pool_admit`'s admission JOINs are **not** the explanation: `PoolAdmit::prepare` turns on from the SCHEMA (`symbols.contribution_id` + `component_capabilities` exist), not from whether a package is installed, so both legs carry every admission join. The cause is not yet known. For scale: the 2026-08-29 regression that motivated `corpus_cost.rs` was **3.2x wall** for byte-identical content, and was treated as a defect rather than blessed. `corpus_cost` cannot see this one — its own doc says why: > THE PLUGIN PATH, ENTIRELY. The pinned corpus installs no packages … so no repo here routes a file to a guest and this ratchet has never executed one. ## Finding 2 — the package leg's `vm_step` is not deterministic Seven consecutive medians-of-three on one box: ``` package vm_step 103,293,096 .. 106,648,538 3.3% spread builtin vm_step 13,108,589 .. 13,112,703 0.04% spread fullscan/sort/autoindex (both legs) stable to 3 units ``` Single readings without the warm-up were worse: 101.5M..111.2M, **9.6%**. The **content** is deterministic — two package-leg indexes of the same tree produce byte-identical symbol and ref projections — so this is cost non-determinism only. `corpus_cost`'s premise is that these counters are "properties of the STATEMENTS and the DATA, not of the machine", proven over eleven passes at 0.02%; that premise does not hold on the package path. The direct consequence: `ruby_package_cost.rs`'s `BAND_UP_PCT` is **8** rather than `corpus_cost`'s 5, i.e. the gate can see a 10% regression in SQLite work and not a 5% one. Tightening it needs this understood first. ## Also worth knowing The blessed `wall_ratio_pct` (350, ceiling 525, floor 227) was measured on a box at load average 6..12 with twelve cores. It should be re-blessed on an isolated runner before it is relied on to catch anything below ~1.5x.

buildagent referenced this issue

2026-09-04 16:15:05 +02:00

gate: full-language migration proof — migrate the Ruby plugin to a package (#80 step 13) #84

buildagent referenced this issue

2026-09-04 16:16:06 +02:00

Every performance ceiling in the plugin subsystem either never runs or cannot fail #116

buildagent referenced this issue

2026-09-04 19:33:45 +02:00

The plugin-tier token ratchet moves ~200 tokens with machine load, so it will flake in CI #126

buildagent commented

2026-09-05 20:17:34 +02:00

Author

Member

The cause is found, and this issue's own framing is what hid it

temp.pool_admit's admission JOINs are not the explanation … The cause is not yet known.

Correct that it is not pool_admit. The reason it stayed unknown is the sentence beside it — "~8x the SQLite work for byte-identical facts". That reads as the same work, done more expensively. It is not. The package leg runs a whole pass the builtin leg does not run at all.

Measured, not inferred

New probe: crates/indexer/tests/package_cost_attribution.rs. It installs the same SQLITE_TRACE_PROFILE hook corpus::work::measure uses, but reads sqlite3_sql() off the statement pointer first, so the same total is bucketed by SQL text instead of summed. Both legs, one process, the same 156 ruby-sinatra files, same fixture as ruby_package_cost.

builtin vm_step 14,828,292  fullscan   170,337
package vm_step 109,729,302  fullscan 4,045,990     ratio 7.40x / 23.75x

Top statements by (package - builtin) vm_step:

excess vm_step	fullscan	execs pkg / builtin	statement
84,744,269	3,838,889	1 / 0	`UPDATE refs SET influence = 2, influence_component_id = COALESCE(…)` — `influence::apply_general` step 3, the COMPETED arm
8,563,240	18,449	1 / 0	`UPDATE refs SET influence = 2, …` (the anchor/bridge follow-up)
2,638,362	18,449	1 / 0	`UPDATE refs SET influence = 1, …` — step 2, ENDPOINT
996,311	18,449	1 / 0	`UPDATE refs SET influence = 0, influence_component_id = NULL …` — step 1, the re-derive CLEAR
73,500	0	1 / 1	`UPDATE refs SET (target_id, resolved_by) = …` — the resolver proper

Excess vm_step 94,901,010; the top five account for 102% of it (over 100% because a few statements are marginally cheaper on the package leg). The four influence statements alone are 96,942,182 — everything.

Note the execs column. builtin 0. Influence::is_builtin_only_index short-circuits when the grant fingerprint is empty, which is every index with no dynamic contribution holding a capability. So on the builtin leg influence::apply_general does not run, and on the package leg it runs once over all 18,450 refs.

What that means for both findings

Finding 1 (the 8x) is INHERENT, and should be ratcheted and named rather than optimised away. Classifying every ref against every dynamic producer's grant is what refs.influence IS — #77's disclosure that a package could have changed this edge. A package-bearing index does strictly more work because it has strictly more to disclose. Comparing it to a builtin leg that skips the pass entirely is not a like-for-like ratio and never was.

But one number in there is not inherent. 3,838,889 fullscan steps on step 3, over 18,450 refs, is ~208 scan steps per ref. apply_general inlines dynamic_admit_select as a correlated subquery — three times in step 2, twice more inside competitors(…) in step 3 — so SQLite re-evaluates the file_contributions ⋈ component_capabilities ⋈ extraction_components relation once per ref row rather than once per pass. Materialising it into an indexed temp table the way PoolAdmit::prepare already materialises temp.pool_admit is a migration-free change to one function, and 97% of the excess fullscan_step sits behind it.

Finding 2 (the non-determinism) is almost certainly the same statement. It is the only one in the pass with a multi-million-step scan whose plan SQLite is free to re-cost between runs; the other three move 18,449 fullscan steps each and the builtin leg holds 0.04%. That is a prediction this probe can settle: re-run it seven times and see whether the 3.3% spread lives in the top bucket. I have not done that — stated rather than implied.

Recommended disposition

Re-frame the issue title. "~8x for byte-identical facts" is a true measurement of a false comparison. It is a fifth pass, not a slower one.
Materialise dynamic_admit_select once per pass in influence::apply_general, mirroring PoolAdmit::prepare. Then re-measure — if the excess fullscan_step collapses and the spread with it, BAND_UP_PCT can come down from 8 toward corpus_cost's 5 and this gate stops being blind to a 5% regression.
Until then, keep the band at 8 and say why in ruby_package_cost's doc — which it already does, honestly, and which is now backed by a cause rather than by an open question.

Not changed by #112

ruby_package_cost passes unmodified with #112's language-profile gate in place (the_package_leg_cost_stays_within_the_blessed_band green, tests/corpus/ruby-package-cost.json untouched). #112 adds two GLOB disjuncts to statements that are not in the top fifteen here.

Caveat on the instrument, since #158 is the adjacent lesson

This probe measures a cold index pass. Like cost-baseline.json it issues no daemon read, so it cannot see a read-path change. Anything about query cost at read time needs a different instrument, and reading this file's silence as approval would be the same mistake.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

## The cause is found, and this issue's own framing is what hid it > `temp.pool_admit`'s admission JOINs are **not** the explanation … **The cause is not yet known.** Correct that it is not `pool_admit`. The reason it stayed unknown is the sentence beside it — *"~8x the SQLite work for **byte-identical facts**"*. That reads as *the same work, done more expensively*. It is not. **The package leg runs a whole pass the builtin leg does not run at all.** ### Measured, not inferred New probe: `crates/indexer/tests/package_cost_attribution.rs`. It installs the same `SQLITE_TRACE_PROFILE` hook `corpus::work::measure` uses, but reads `sqlite3_sql()` off the statement pointer first, so the same total is **bucketed by SQL text** instead of summed. Both legs, one process, the same 156 `ruby-sinatra` files, same fixture as `ruby_package_cost`. ``` builtin vm_step 14,828,292 fullscan 170,337 package vm_step 109,729,302 fullscan 4,045,990 ratio 7.40x / 23.75x ``` Top statements by `(package - builtin)` vm_step: | excess vm_step | fullscan | execs pkg / builtin | statement | |---:|---:|---|---| | **84,744,269** | **3,838,889** | **1 / 0** | `UPDATE refs SET influence = 2, influence_component_id = COALESCE(…)` — `influence::apply_general` step 3, the COMPETED arm | | 8,563,240 | 18,449 | **1 / 0** | `UPDATE refs SET influence = 2, …` (the anchor/bridge follow-up) | | 2,638,362 | 18,449 | **1 / 0** | `UPDATE refs SET influence = 1, …` — step 2, ENDPOINT | | 996,311 | 18,449 | **1 / 0** | `UPDATE refs SET influence = 0, influence_component_id = NULL …` — step 1, the re-derive CLEAR | | 73,500 | 0 | 1 / 1 | `UPDATE refs SET (target_id, resolved_by) = …` — the resolver proper | **Excess vm_step 94,901,010; the top five account for 102% of it** (over 100% because a few statements are marginally *cheaper* on the package leg). The four `influence` statements alone are 96,942,182 — everything. Note the `execs` column. `builtin 0`. `Influence::is_builtin_only_index` short-circuits when the grant fingerprint is empty, which is every index with no dynamic contribution holding a capability. So on the builtin leg `influence::apply_general` **does not run**, and on the package leg it runs once over all 18,450 refs. ### What that means for both findings **Finding 1 (the 8x) is INHERENT, and should be ratcheted and named rather than optimised away.** Classifying every ref against every dynamic producer's grant is what `refs.influence` IS — #77's disclosure that a package could have changed this edge. A package-bearing index does strictly more work because it has strictly more to disclose. Comparing it to a builtin leg that skips the pass entirely is not a like-for-like ratio and never was. **But one number in there is not inherent.** 3,838,889 fullscan steps on step 3, over 18,450 refs, is **~208 scan steps per ref**. `apply_general` inlines `dynamic_admit_select` as a correlated subquery — three times in step 2, twice more inside `competitors(…)` in step 3 — so SQLite re-evaluates the `file_contributions ⋈ component_capabilities ⋈ extraction_components` relation once per ref row rather than once per pass. Materialising it into an indexed temp table the way `PoolAdmit::prepare` already materialises `temp.pool_admit` is a migration-free change to one function, and 97% of the excess `fullscan_step` sits behind it. **Finding 2 (the non-determinism) is almost certainly the same statement.** It is the only one in the pass with a multi-million-step scan whose plan SQLite is free to re-cost between runs; the other three move 18,449 fullscan steps each and the builtin leg holds 0.04%. That is a prediction this probe can settle: re-run it seven times and see whether the 3.3% spread lives in the top bucket. I have not done that — stated rather than implied. ### Recommended disposition 1. **Re-frame the issue title.** "~8x for byte-identical facts" is a true measurement of a false comparison. It is a fifth pass, not a slower one. 2. **Materialise `dynamic_admit_select` once per pass** in `influence::apply_general`, mirroring `PoolAdmit::prepare`. Then re-measure — if the excess `fullscan_step` collapses and the spread with it, `BAND_UP_PCT` can come down from 8 toward `corpus_cost`'s 5 and this gate stops being blind to a 5% regression. 3. **Until then, keep the band at 8 and say why in `ruby_package_cost`'s doc** — which it already does, honestly, and which is now backed by a cause rather than by an open question. ### Not changed by #112 `ruby_package_cost` passes unmodified with #112's language-profile gate in place (`the_package_leg_cost_stays_within_the_blessed_band` green, `tests/corpus/ruby-package-cost.json` untouched). #112 adds two `GLOB` disjuncts to statements that are not in the top fifteen here. ### Caveat on the instrument, since #158 is the adjacent lesson This probe measures a **cold index pass**. Like `cost-baseline.json` it issues no daemon read, so it cannot see a read-path change. Anything about query cost at read time needs a different instrument, and reading this file's silence as approval would be the same mistake. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent commented

2026-09-06 00:55:00 +02:00

Author

Member

BUILD IT — built, measured, and BOTH findings are closed by the one change

The previous comment recommended materialising dynamic_admit_select and said "then re-measure — if the excess fullscan_step collapses and the spread with it, BAND_UP_PCT can come down." Done, and it did both.

influence::apply_general now builds temp.influence_dyn_admit once per pass, with indexes on contribution_id and file_id, and the eight correlated-subquery sites read the table. That mirrors capabilities::PoolAdmit::prepare for the reason that function already gives: an admission relation is a property of the GENERATION, not of the row being classified. Migration-free, one function, and the relation it re-derived per ref holds six rows.

Finding 1 — the excess

Measured by this issue's own probe (crates/indexer/tests/package_cost_attribution.rs), same 156 ruby-sinatra files, same fixture, one process, both legs:

dimension	before	after	change
package `vm_step`	107,650,069	25,973,355	−75.9%
package `fullscan_step`	4,045,989	549,751	−86.4%
ratio `vm_step` (pkg/builtin)	6.88x	1.66x
ratio `fullscan_step`	23.76x	3.23x
step 3, the COMPETED arm, `vm_step`	81,835,851	3,056,971	−96.3%
step 3, `fullscan_step`	3,838,889	342,563	−91.1%
builtin leg `vm_step`	15,644,071	15,645,903	+0.01%

The builtin leg is unmoved. That is what says this is the package pass and not the machine.

The remaining 1.66x is the inherent part this issue's previous comment identified and which should stay: apply_general runs once on the package leg and zero times on the builtin one, because Influence::is_builtin_only_index short-circuits on an empty grant fingerprint. A package-bearing index has strictly more to disclose.

Finding 2 — the non-determinism went with it, which is what identifies the cause

The prediction was "almost certainly the same statement … that is a prediction this probe can settle." Settled. Four consecutive SINGLE readings — no median, no warm-up, the harshest case, the one that used to spread 9.6%:

25,969,584   25,972,995   25,979,318   25,973,355        0.037%

against the BUILTIN leg's 0.04% in the same runs. The 3.3% spread lived in the multi-million-step scan, and it is gone because the scan is.

So BAND_UP_PCT comes down from 8 to 5, corpus_cost's value: 5% is now a 135x margin over measured noise, the same shape corpus_cost has, and this gate can see a 5% SQLite regression again instead of only a 10% one.

The mutations, RUN

Materialisation drops rows — build the table with WHERE 0. RESULT: RED, 10 of 12 influence_classification tests, e.g. left: (Some(0), None) right: (Some(2), Some(9)).

The rebuild — replace DROP TABLE IF EXISTS with CREATE TEMP TABLE IF NOT EXISTS. RESULT: SURVIVOR — 12 passed, 0 failed.

That survivor is a finding about the change itself and it is worth stating plainly: materialising buys a staleness hazard that the subquery form could not have. A temp table belongs to the CONNECTION, not the transaction, so a second pass on one connection reads the first pass's grants unless the build drops it — and every pass in that file opened a fresh connection, so nothing in the repository graded it. a_revoked_grant_does_not_survive_in_the_materialised_admission_set runs two passes on ONE connection with the grant revoked between them; under that mutation it is RED and it is the only test that is.

And a gate died in the process — recorded, not papered over

ruby-package-cost.json's wall_ratio_pct fell from 350 to 142, and RATIO_DOWN_PCT's own doc says what the floor is for: "a package leg that silently ran the BUILTIN pass instead reads as ~100." At 35% the floor is now 92 — below the very reading it exists to refuse. A bound that cannot reach its own case is not a bound.

Narrowing it to 25 (floor ~107) is not available either, because the ratio's noise grew as the ratio shrank: two median-of-3 runs minutes apart on this box, at load average 22..29, read 101 and 142 — a 40% swing on a quantity whose whole spread used to be 17%. A floor at 107 would go red on an honest run.

So the floor is widened to 55 and demoted in writing: it is a coarse tripwire, and the job of proving the two legs are two belongs to the four structural controls that run BEFORE any bound is read — equal symbol counts, non-zero package-language files, zero builtin-ruby files on the package leg, both legs executing SQLite work. Those are contention-immune, which a wall clock never was. All four held across every measurement above.

On the re-frame

Agreed and applied where it counts: BAND_UP_PCT's doc, ruby-package-cost.json's bless reason and _prdoc/records/84-P4-parity-deltas.md §4.1 now all say the 8x was a fifth pass rather than a slower one. The issue title is still the old framing; renaming it is the owner's call.

Caveat on the instrument, unchanged

This is still a COLD INDEX measurement. It issues no daemon read and cannot see a read-path change. Nothing here says anything about query cost at read time.

Commit 5876b74 on wip/rubypkg, based on integration at a33210d.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

## BUILD IT — built, measured, and BOTH findings are closed by the one change The previous comment recommended materialising `dynamic_admit_select` and said *"then re-measure — if the excess `fullscan_step` collapses and the spread with it, `BAND_UP_PCT` can come down."* Done, and it did both. `influence::apply_general` now builds `temp.influence_dyn_admit` once per pass, with indexes on `contribution_id` and `file_id`, and the eight correlated-subquery sites read the table. That mirrors `capabilities::PoolAdmit::prepare` for the reason that function already gives: an admission relation is a property of the GENERATION, not of the row being classified. Migration-free, one function, and the relation it re-derived per ref **holds six rows**. ### Finding 1 — the excess Measured by this issue's own probe (`crates/indexer/tests/package_cost_attribution.rs`), same 156 `ruby-sinatra` files, same fixture, one process, both legs: | dimension | before | after | change | |---|---:|---:|---:| | package `vm_step` | 107,650,069 | **25,973,355** | **−75.9%** | | package `fullscan_step` | 4,045,989 | **549,751** | **−86.4%** | | ratio `vm_step` (pkg/builtin) | 6.88x | **1.66x** | | | ratio `fullscan_step` | 23.76x | **3.23x** | | | step 3, the COMPETED arm, `vm_step` | 81,835,851 | **3,056,971** | **−96.3%** | | step 3, `fullscan_step` | 3,838,889 | **342,563** | −91.1% | | **builtin leg `vm_step`** | 15,644,071 | 15,645,903 | **+0.01%** | The builtin leg is unmoved. That is what says this is the package pass and not the machine. The remaining 1.66x is the inherent part this issue's previous comment identified and which should stay: `apply_general` runs once on the package leg and zero times on the builtin one, because `Influence::is_builtin_only_index` short-circuits on an empty grant fingerprint. A package-bearing index has strictly more to disclose. ### Finding 2 — the non-determinism went with it, which is what identifies the cause The prediction was *"almost certainly the same statement … that is a prediction this probe can settle."* Settled. Four consecutive **SINGLE** readings — no median, no warm-up, the harshest case, the one that used to spread **9.6%**: ``` 25,969,584 25,972,995 25,979,318 25,973,355 0.037% ``` against the BUILTIN leg's 0.04% in the same runs. The 3.3% spread lived in the multi-million-step scan, and it is gone because the scan is. So `BAND_UP_PCT` comes down from **8 to 5**, `corpus_cost`'s value: 5% is now a 135x margin over measured noise, the same shape `corpus_cost` has, and this gate can see a 5% SQLite regression again instead of only a 10% one. ### The mutations, RUN **Materialisation drops rows** — build the table with `WHERE 0`. RESULT: **RED, 10 of 12** `influence_classification` tests, e.g. `left: (Some(0), None) right: (Some(2), Some(9))`. **The rebuild** — replace `DROP TABLE IF EXISTS` with `CREATE TEMP TABLE IF NOT EXISTS`. RESULT: **SURVIVOR — 12 passed, 0 failed.** That survivor is a finding about the change itself and it is worth stating plainly: **materialising buys a staleness hazard that the subquery form could not have.** A temp table belongs to the CONNECTION, not the transaction, so a second pass on one connection reads the first pass's grants unless the build drops it — and every pass in that file opened a fresh connection, so nothing in the repository graded it. `a_revoked_grant_does_not_survive_in_the_materialised_admission_set` runs two passes on ONE connection with the grant revoked between them; under that mutation it is RED and **it is the only test that is**. ### And a gate died in the process — recorded, not papered over `ruby-package-cost.json`'s `wall_ratio_pct` fell from 350 to 142, and `RATIO_DOWN_PCT`'s own doc says what the floor is for: *"a package leg that silently ran the BUILTIN pass instead reads as ~100."* At 35% the floor is now **92 — below the very reading it exists to refuse.** A bound that cannot reach its own case is not a bound. Narrowing it to 25 (floor ~107) is not available either, because the ratio's noise grew as the ratio shrank: two median-of-3 runs minutes apart on this box, at load average 22..29, read **101 and 142** — a 40% swing on a quantity whose whole spread used to be 17%. A floor at 107 would go red on an honest run. So the floor is widened to 55 and **demoted in writing**: it is a coarse tripwire, and the job of proving the two legs are two belongs to the four structural controls that run BEFORE any bound is read — equal symbol counts, non-zero package-language files, zero builtin-ruby files on the package leg, both legs executing SQLite work. Those are contention-immune, which a wall clock never was. All four held across every measurement above. ### On the re-frame Agreed and applied where it counts: `BAND_UP_PCT`'s doc, `ruby-package-cost.json`'s bless reason and `_prdoc/records/84-P4-parity-deltas.md` §4.1 now all say the 8x was a fifth pass rather than a slower one. The issue title is still the old framing; renaming it is the owner's call. ### Caveat on the instrument, unchanged This is still a COLD INDEX measurement. It issues no daemon read and cannot see a read-path change. Nothing here says anything about query cost at read time. Commit `5876b74` on `wip/rubypkg`, based on `integration` at `a33210d`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

dhoyer referenced this issue from a commit

2026-09-06 02:05:02 +02:00

perf(#113): the package leg's admission relation is derived once per pass, not once per ref

dhoyer referenced this issue from a commit

2026-09-06 02:05:02 +02:00

merge wip/rubypkg: #102 packaged half, #113 admission relation, offer-prose compressions

dhoyer referenced this issue from a commit

2026-09-06 06:05:59 +02:00

gate: the last two records re-measured after #165, each for a named reason

buildagent commented

2026-09-06 09:39:34 +02:00

Author

Member

Triage 2026-09-06: CLOSING. Both findings — the 8× cost and the non-determinism — fell to one change, and the band was tightened rather than widened.

Verified against master. Landed as 09cc387, re-measured in f6a878a.

The change

const DYN_ADMIT: &str = "temp.influence_dyn_admit" — crates/indexer/src/influence.rs:410; materialize_dyn_admit at :417, building the table with indexes on contribution_id and file_id, rebuilt per pass (staleness reasoning at :405-409). The admission relation is derived once per pass instead of once per ref.

The measurement, on this box, this run

dimension	issue body	now
`vm_step` ratio (pkg/builtin)	8.1×	1.66× (15,607,971 → 25,887,874)
`fullscan_step` ratio	23.0×	3.21× (169,601 → 544,351)
wall ratio	350%	159%
step-3 COMPETED arm fullscan	3,838,889	338,073

f6a878a's own record puts the corpus-side figures at vm_step 109,095,227 → 25,865,288 (−76.3%) and fullscan_step 4,045,989 → 541,182 (−86.6%), against a prediction of −75.9% / −86.4% made before the run. A prediction that lands that close is what separates a real attribution from a harness artifact.

The band went DOWN, which is the part that makes this a close

BAND_UP_PCT: i64 = 5 — crates/indexer/tests/ruby_package_cost.rs:102, down from 8 to match corpus_cost. Finding 2's residual non-determinism now has to fit inside a tighter gate than the one it was filed against. A cost issue closed by widening its own ratchet would not be closed at all.

The staleness hazard the materialisation introduces is graded: a_revoked_grant_does_not_survive_in_the_materialised_admission_set — crates/indexer/tests/influence_classification.rs. That is the right test to have written, because caching an admission relation is exactly how a revoked grant survives.

Runs (exit 0, corpus mounted)

cargo test -p code-index-indexer --test influence_classification  → 13 passed
COSI_CORPUS_DIR=$HOME/.cache/cosi-corpus COSI_CORPUS_REQUIRE=1 \
  cargo test -p code-index-indexer --test ruby_package_cost --test package_cost_attribution -- --nocapture
                                                                  → 1 + 3 passed
corpus[package_cost_attribution]: executed=1 unavailable=0 ... controls=2 (require=true)
corpus[ruby_package_cost]:        executed=1 unavailable=0 ... controls=3 (require=true)

Non-zero executed= on both — not the executed=0 unavailable=1 false green.

Residual, named

The remaining 1.66× is the inherent extra influence::apply_general pass. It is not a defect and should stay; what it should not do is drift, which the 5% band now enforces. f6a878a's record also notes the condition gate refused the old band by name (0.3.0 against a leg running 0.4.0) and demanded a re-measure rather than a re-bless — so this number is attached to the conditions it was taken under.

🤖 Triage lane, 2026-09-06, master 45cf6e4

## Triage 2026-09-06: CLOSING. Both findings — the 8× cost and the non-determinism — fell to one change, and the band was tightened rather than widened. Verified against master. Landed as `09cc387`, re-measured in `f6a878a`. ### The change `const DYN_ADMIT: &str = "temp.influence_dyn_admit"` — `crates/indexer/src/influence.rs:410`; `materialize_dyn_admit` at `:417`, building the table with indexes on `contribution_id` and `file_id`, rebuilt **per pass** (staleness reasoning at `:405-409`). The admission relation is derived once per pass instead of once per ref. ### The measurement, on this box, this run | dimension | issue body | now | |---|---:|---:| | `vm_step` ratio (pkg/builtin) | 8.1× | **1.66×** (15,607,971 → 25,887,874) | | `fullscan_step` ratio | 23.0× | **3.21×** (169,601 → 544,351) | | wall ratio | 350% | 159% | | step-3 COMPETED arm fullscan | 3,838,889 | 338,073 | `f6a878a`'s own record puts the corpus-side figures at `vm_step` 109,095,227 → 25,865,288 (**−76.3%**) and `fullscan_step` 4,045,989 → 541,182 (**−86.6%**), against a prediction of −75.9% / −86.4% made **before** the run. A prediction that lands that close is what separates a real attribution from a harness artifact. ### The band went DOWN, which is the part that makes this a close `BAND_UP_PCT: i64 = 5` — `crates/indexer/tests/ruby_package_cost.rs:102`, down from 8 to match `corpus_cost`. Finding 2's residual non-determinism now has to fit inside a **tighter** gate than the one it was filed against. A cost issue closed by widening its own ratchet would not be closed at all. The staleness hazard the materialisation introduces is graded: `a_revoked_grant_does_not_survive_in_the_materialised_admission_set` — `crates/indexer/tests/influence_classification.rs`. That is the right test to have written, because caching an admission relation is exactly how a revoked grant survives. ### Runs (exit 0, corpus mounted) ``` cargo test -p code-index-indexer --test influence_classification → 13 passed COSI_CORPUS_DIR=$HOME/.cache/cosi-corpus COSI_CORPUS_REQUIRE=1 \ cargo test -p code-index-indexer --test ruby_package_cost --test package_cost_attribution -- --nocapture → 1 + 3 passed corpus[package_cost_attribution]: executed=1 unavailable=0 ... controls=2 (require=true) corpus[ruby_package_cost]: executed=1 unavailable=0 ... controls=3 (require=true) ``` Non-zero `executed=` on both — not the `executed=0 unavailable=1` false green. ### Residual, named The remaining **1.66×** is the inherent extra `influence::apply_general` pass. It is not a defect and should stay; what it should not do is drift, which the 5% band now enforces. `f6a878a`'s record also notes the condition gate refused the old band **by name** (0.3.0 against a leg running 0.4.0) and demanded a re-measure rather than a re-bless — so this number is attached to the conditions it was taken under. 🤖 Triage lane, 2026-09-06, master `45cf6e4`

buildagent closed this issue

2026-09-06 09:39:36 +02:00

buildagent referenced this issue from a commit

2026-09-27 14:52:30 +02:00

record: the Ruby package's end-to-end overhead, cold and warm

buildagent referenced this issue

2026-09-27 15:03:26 +02:00

epic: every builtin language becomes a first-party plugin package #309

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

h-dv/code-index#113

No description provided.

Rows
Columns

The package path costs ~8x the builtin path in SQLite work for byte-identical facts, and its vm_step is non-deterministic #113

The setup

Finding 1 — 8x the SQLite work for the same rows

Finding 2 — the package leg's vm_step is not deterministic

Also worth knowing

The cause is found, and this issue's own framing is what hid it

Measured, not inferred

What that means for both findings

Recommended disposition

Not changed by #112

Caveat on the instrument, since #158 is the adjacent lesson

BUILD IT — built, measured, and BOTH findings are closed by the one change

Finding 1 — the excess

Finding 2 — the non-determinism went with it, which is what identifies the cause

The mutations, RUN

And a gate died in the process — recorded, not papered over

On the re-frame

Caveat on the instrument, unchanged

Triage 2026-09-06: CLOSING. Both findings — the 8× cost and the non-determinism — fell to one change, and the band was tightened rather than widened.

The change

The measurement, on this box, this run

The band went DOWN, which is the part that makes this a close

Runs (exit 0, corpus mounted)

Residual, named

Finding 2 — the package leg's `vm_step` is not deterministic