Cache target mappings and raise packing iteration budget

[imrishabh18]

Summary

• cache rotated pad offsets and network target mappings by rotation while packing a component
• share that cache across every outline-segment candidate created by SingleComponentPackSolver
• clear the cache for each component-placement run
• raise PackSolver2's iteration budget from 100,000 to 500,000
• run the large weighted-connections repro as a completion regression

Why

Each OutlineSegmentCandidatePointSolver previously rebuilt the same mapping from the component's pads to already-packed target pads. That mapping depends on the component, its rotation, and the fixed set of packed components—not the outline segment—so viable segments repeated expensive pad and weighted-connection scans.

The large repro also could not finish under the inherited 100,000-step limit. PackSolver2 counts nested candidate and optimizer work against its parent budget, and the captured 218-component board needs about 246,892 parent steps. The increased limit gives large valid boards enough room to complete.

Impact

• The same 100,000-step partial workload decreased from about 55.97s on main to 30.22s with the cache.
• 31,394 viable candidates collapse to only 504 component/rotation mapping constructions.
• With the 300,000-step budget, the full repro packs all 218 components successfully in about 83.36s instead of failing after 126 components.

Validation

• bun run typecheck
• bun test tests/network-target-mapping-cache.test.ts tests/outline-candidate-fit-rejection.test.ts tests/PackSolver2.test.ts tests/PackSolver2_01.test.ts — 7 pass, 0 fail
• bun test tests/repros/repro-large-weighted-connections.test.ts — 2 pass, 0 fail
• Biome formatting and git diff --check

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
calculate-packing	Ready	Preview	Aug 6, 2026 10:51am