[FBumann]

Replaces #511, rebased on today's main and re-measured. Implements #508. Close #511 in favour of this.

Why it is not just a rebase

#511 measured −11% on profiled/l. This measures −32%, on the same case, for the same idea — because two things changed under it.

#541 made the ordinal free. encode_dimensions now makes every string dimension an Enum over its labels in ordinal order, so the physical code already is the ordinal: to_physical(), no lookup. #511 collected the dimension table into a Python dict and paid replace_strict per row per dim, which on profiled is two of three dimensions. Only a non-string dimension still needs the dictionary, and it is built from the small side — one entry per label, not per row.

The measurement had to be redone anyway. #511's numbers predate #541 and #550 (CSR), and docs/benchmarks.md still publishes from 1 Aug. The 1.46x-vs-linopy figure quoted in #511 is three engine changes stale, so the case for the change had to be re-established rather than carried over.

The change

profiled's own model header diagnosed this before either PR existed:

a parameter already dense over the variable product is the array xarray wants, needing neither broadcast nor alignment, while we join a full-size frame against a full-size coordinate product

On today's main that join is the largest single query in the build — 0.84 s of a profiled/l build, 23% (python -m bench.profile_build profiled l).

Position can mean the coordinate here too. The label frame is in label order by construction — not lexicographic dim order, which is why sorting the parameter by its dim columns does not match it, but row-major over the product in each dimension's own index order. A row's position is therefore computable from its own coordinates, and the values scatter into that order with no join at all.

Measured

Interleaved A/B, both arms in one process, the branch toggled so only the decision differs. Median of paired ratios, 7 rounds:

profiled/l   1.325 s -> 0.923 s    0.684x   all [0.684, 0.694, 0.724, 0.668, 0.672, 0.682, 0.738]
dispatch/l   0.193 s -> 0.194 s    1.005x   (gate declines — bounds are per-generator)
transport/l  0.613 s -> 0.627 s    1.023x   (gate declines — bounds are per-node)

The fast path fires on the shape it targets and nowhere else. The two controls are within noise of 1.0 and their pairs straddle it.

The gate is the whole correctness argument

A wrong bound is a wrong model with no error, so the attach is refused unless every one of these holds — each a fact already computed elsewhere:

dims exactly the variable's, in order	fewer broadcast, more is already refused, a different order is a different row-major walk
the variable declares no where	a mask makes the label frame a subset of the product, and position stops lining up
the parameter is dense	height equals the product of the cardinalities binding cached
no duplicate coordinates	would break density without changing the height — refused earlier by check_one_row_per_coordinate

Three tests, carried over from #511 and adjusted to the scatter: the attached path against the linopy oracle; the same numbers arriving shuffled, which is what an attach trusting source order gets silently wrong; and both refusals.

Interaction with #520

#520 rewrites the same bounds method — it drops maintain_order='left' and guarantees the order with a verified sort in _build_variable instead. This PR is additive against that: the attach provides position rather than preserving it, so it is correct under either mechanism, but whichever merges second reconciles one hunk. Landing this first is the smaller reconciliation.

Not taken

Keeping it lazy with pl.concat(how='horizontal') measured slightly faster in #511, but polars deprecates that concat's height padding in favour of requiring equal heights — exactly the precondition the gate checks — so the natural spelling warns until that release, and this repo treats warnings as errors. Still worth revisiting; the floor here is 1.30 and we run 1.43.

942 passed · ruff clean · pyrefly 0 errors.

🤖 Generated with Claude Code

[codspeed]

Merging this PR will degrade performance by 9.97%

⚡ 1 improved benchmark
❌ 2 regressed benchmarks
✅ 11 untouched benchmarks
⏩ 38 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Memory	test_emit[sector-s-lpspec-highs]	3.9 MB	5 MB	-22.14%
❌	Memory	test_emit[sector-s-lpspec-lp]	4.9 MB	5.6 MB	-12.62%
⚡	Memory	test_emit[profiled-s-lpspec-lp]	23.6 MB	22 MB	+7.27%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing perf/bounds-attach-rebased (4948fcc) with main (ad81c35)}

Footnotes

1. 38 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[FBumann]

Superseded by #568. #511 merged while this was open, and it turned out to already contain the mechanism — the scatter and the whole gate. The only thing this PR had that main lacks is the Enum ordinal, so #568 is that as a 15-line delta instead of a wholesale replacement, with the same measured result (profiled/l 1.240 s -> 0.901 s).