Optimisation passes

The work that only happens if it's on the schedule

An optimisation pass is a dedicated block of time — calendared, resourced, owned by someone — set aside to make a system or asset cheaper to run. The word "pass" matters: it implies iteration, a second look at something already working, with the specific goal of reducing cost without changing the result.

The alternative to a scheduled pass is hoping that things will be fast enough. They rarely are. Performance problems compound: a level that runs at fifty-eight frames per second in isolation drops to forty-two once audio, AI, and particle systems are all running together. By the time the problem is obvious, it is usually late in the project, where fixing it competes with certification prep and day-one build work.

Good production schedules treat optimisation as a phase, not a footnote. Common pass types — rendering, audio, memory, loading — each require a different specialist and a different toolset. A rendering pass might involve batching draw calls, reducing overdraw, or switching from dynamic to baked lighting in areas where the dynamism adds nothing. A memory pass audits texture budgets, evicts assets that loaded in speculatively, and flags anything holding more resident memory than its per-asset allocation allows. A loading pass looks at streaming, asset ordering on disc, and whether anything is blocking the main thread during a transition.

Each pass starts with a profiling session. Without measurement, the work is guesswork, and the optimisations that feel significant often aren't. The systemic problems — the ones that account for most of the frame time or most of the memory — are frequently invisible until you look at the data. Profiling before any pass is non-negotiable; otherwise, you are polishing the wrong surface.

Timing within the project matters enormously. A rendering pass run immediately after the vertical slice is different from one run in the last six weeks of production. Early passes are exploratory — they establish the real cost of systems and sometimes discover that an approach needs rearchitecting, not tweaking. Late passes are surgical: the scope is fixed, the assets are nearly final, and the goal is hitting the frame target without breaking anything. Both are necessary, and neither substitutes for the other.

The single most common failure mode is scheduling one pass when three are needed. Each pass cleans the easy problems; a second pass, working on a cleaner baseline, finds the harder ones. Budget two or three rounds from the start, or you will improvise them under pressure at the end — which is a bad time to be making changes to load-bearing systems.

By the time the problem is obvious, it is usually late in the project, where fixing it competes with certification prep and day-one build work.

Every figure in this entry is a worked example, not a measurement of any particular production. It is not a measurement of any particular production.