From 1a684c072daa96f4b1d626d8ca3d3c23fc86d0f5 Mon Sep 17 00:00:00 2001 From: Lilleman auf Larv Date: Tue, 6 Oct 2026 13:29:46 +0200 Subject: [PATCH] Answer prose round 3: the no-margin rule states its reason the right way round, and the performance gate decision names goal 13 --- docs/decisions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/decisions.md b/docs/decisions.md index 8b35d25..b14c1c4 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -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