Public benchmarks

Our nesting densities, measured on our corpus of edge cases — open method, reproducible numbers.

Run conditions : Docker worker on an AMD Ryzen 9 9900X (12 cores/24 threads), 4 vcores allocated per job, 90 s budget — Docker images from commit d890c92, 2026-09-13. — deployed image d8f7fc6

Method

Every case is a standard product job (multi-sheet BPP, one –X direction, nesting-in-cutouts on). Material density is measured on the verified report: area of the placed parts over the area of the used sheets. Physical validation checks zero overlap, every part inside its sheet, and a minimal gap no smaller than the requested spacing.

Results by case

CaseGeometrySheetsSpacingPartsMaterial densityPhysics
T-ARinged part (100×100 mm, Ø35 cutout) + 4-lobed fan nesting inside the cutouts — the reference corpus (100 + 800 parts)2 × 1000×10000.1 mm900/90055.4%verified
T-BThree close rectangle classes (300×200, 250×180, 120×90) — pure lattice packing3 × 1500×10002 mm80/8084.4%verified
T-CNon-convex L (200×200) and U (240×200) parts2 × 1200×10001 mm60/6060%verified
T-DLong thin parts (900×40) + 300 small rectangles — one dominant orientation2 × 1000×10001 mm330/33076.5%verified
T-ERinged part + fan with free rotations every 30° (12 orientations)3 × 1000×10000.1 mm460/46061.5%verified
T-F90 rectangles 200×150 on two sheet formats (cost ∝ area) — tight stock1000×1000 + 2000×10001 mm90/9090%verified
T-GOne near-full-sheet part (950×950) + 200 small parts around it2 × 1000×10000.5 mm201/20160.1%verified
T-HSingle class of 200 identical rectangles (120×80) — annealing at steady state3 × 1000×10001 mm200/20064%verified
T-JSame as A but 1000 parts on ONE 1000×2000 sheet at 4 mm — over capacity on purpose1 × 1000×20004 mmrefused before computehonest refusal < 1 s
T-K1000 parts at 2.4 mm on two 1000×1000 sheets — right at the measured packing limit2 × 1000×10002.4 mm1000/100058.5%verified

“Verified” = zero measured overlap, every part inside its sheet, minimal gap never below the requested spacing.

Robustness beyond the numbers

The internal torture corpus also runs a free-form ESICUP instance (shirts, 12 orientations) and a 12-orientation variant of case A. Those live in their own normalized units, so their density is not comparable to the product cases above — they exist to prove the engine never overlaps, never drops a part, and never returns an uncuttable layout on unfamiliar geometry.

What we do NOT claim: these densities are ours, on our corpus, at the stated budgets — not a third-party certification, and no benchmark makes one engine universally “best”. Every number above was produced by the exact Docker image deployed in production at the date shown, and re-verified after each engine release.