Answer prose round 3: the no-margin rule states its reason the right way round, and the performance gate decision names goal 13

This commit is contained in:
2026-10-06 13:29:46 +02:00
committed by Lillem4n
parent fb3fb16deb
commit 1a684c072d
+3 -3
View File
@@ -391,7 +391,7 @@ cost.
## The performance gate asserts allocations, not wall-clock time
2026-09-03, Lilleman auf Larv.
2026-09-03, Lilleman auf Larv. Goal 13.
`AllocsPerRun` is deterministic across machines, so a 10% ceiling does not flake under
CI load, while time varies with the machine and its neighbours. A rendering slowdown
@@ -399,8 +399,8 @@ almost always costs an allocation too (a lost pre-size, a per-item map, an extra
The benchmark suite (the README's Development) reports time for a human, not as a pass/fail gate.
A case guarding against one allocation per render, such as a render's scope reaching the
heap through `pickKey.under`, holds at its baseline with no margin, since 10% of its
count is less than one allocation. Lilleman auf Larv decided it on 2026-10-06.
heap through `pickKey.under`, holds at its baseline with no margin: from a baseline of
10, a 10% margin lets that allocation through. Lilleman auf Larv decided it on 2026-10-06.
## Rows live in a TSV, the shape in JSON