mirror of
https://github.com/ajisaacs/OpenNest.git
synced 2026-11-11 12:11:09 -05:00
ajandClaude Opus 5.5
beccbae106
One Irregular decode of a small job took seconds because each block in the catalog is built by the full Fill pipeline (PrivatePlateFill), and inside it StripeFiller's estimate rows spent about 85% of the CPU in FillLinear's perpendicular TilePattern. A stripe estimate is exactly one pattern tall, so the pattern's copy distance, an all-pairs slide search, always exceeded the room left and the copies were discarded after the search had run in full. TilePattern now passes FindPatternCopyDistance the largest distance that could still place a copy: for a whole copy, the room past the pattern; for a pattern that may tile partially, the most room past any one of its parts. The distance is the maximum over every pair, so the search stops as soon as it passes that bound and the tile returns empty, which is what the full search led to. The public CopyDistance is unchanged. StripeFiller's angle searches also reuse each rotated pattern's bounding box per angle instead of cloning and rotating the parts again on every probe. Output is identical: the layouts of every benchmark job that finishes match the previous build. Measured A/B on this machine, alternating builds per job (Benchmark --engines Irregular --parallel 1, benchmark ms): - N26-2A5: 15.5 s -> 8.8 s (12.6 s -> ~7.2 s in quieter runs) - 73 of the 80 bench jobs (the other 7 time out at 5 minutes in both builds): 1,990 s -> 1,578 s total (-21%), process CPU 6,486 s -> 3,842 s (-41%), median job 0.91x. N26-295 now finishes in 242 s with the same layout where it hit the 5-minute limit before. - Problem-nest corpus auto-nest and fill areas: all at baseline. A parallel herringbone pair build was tried and dropped: it saved 1.2 s on N26-2A5 but cost 10 s and 45 s more CPU on P241017-01. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>