the optimisation that is slower, kept on purpose

The core loop of a memory-hard puzzle generator is a trimming pass: visit a very large edge set repeatedly, drop nodes that have only one neighbour, stop when nothing changes. Each pass needs counts per region, and the counts have to be re-zeroed between passes. That clearing was the bottleneck, not the traversal.

Two moves followed. First, stop clearing: carry a generation counter per region so that bumping one number invalidates the whole table, which brought the approach to parity with the straightforward version and halved its memory. Second, reorder the survivors from one traversal order into the other, so the next pass reads memory sequentially. That second move was built, measured, and it lost by a few percent — the copy cost more than the locality it bought at the problem sizes we can actually run.

We kept it. It sits behind a compile-time flag, unused, next to a table recording four variants and their measurements, and a note stating the problem size at which the arithmetic should flip in its favour. Deleting it would mean paying again for the same knowledge in a year, with no record that it had already been paid for.

The cost is a dormant branch that must be maintained or retired on a date, and a benchmark suite larger than the code it measures.

The habit underneath is the point. A rejected optimisation is a result, and it stays a result only if the measurement, the rejection and the condition that would reverse it are all written where the next person will find them.

What it proves: this team keeps its own negative results with the conditions attached, which is the difference between a benchmark and an anecdote.