Reproduce a performance problem, profile the target build, test one focused change and retain comparable measurements with regression coverage.
Record the player-visible symptom, target hardware, build revision, scene, input sequence and quality settings. Choose measurable acceptance conditions for that scenario. Convert a chosen FPS target to its frame interval, but retain individual frame times and slow-frame evidence; an average can hide stutter.
Profile the built game on the intended device and collect CPU, GPU, memory/allocation and relevant I/O observations. Identify the frame or phase that exceeds the acceptance condition and trace the work causing it. Check synchronization before adding CPU and GPU timings together; overlapping pipelines do not form a simple summed budget.
If CPU submission work is limiting, compare a chosen time allowance with an observed cost per submission. If a texture is implicated, inspect its actual format and exact mip data. For a resolution change, compare pixel counts with a stated reference. For particle storage, enter the allocated layout and copies. Select only the model that matches the evidence.
Apply a focused change with a reversible revision, then rerun the same input sequence and measurement conditions. Compare the relevant timing distribution, resource measurements and visible quality. Look for shifted costs such as load time, memory, artifacts or input response; an improved average in one scene can conceal a regression elsewhere.
Generate named build/configuration/test combinations for startup, representative scenes, transitions, stress content and extended sessions. Record actual outcomes and reproduction evidence, including accessibility and quality settings affected by the change. Mark excluded cases with a reason and keep unresolved failures visible.
Document the symptom, measured cause, change and final acceptance evidence. Save the comparison note, profiler captures and complete matrix backup with the build revision. Assign an owner to repeat the relevant measurement when assets, engine versions or rendering code change.
Convert the chosen frame-rate target to a comparison interval.
Draft and download the reproducible performance comparison record.
Compare measured submission cost with an explicit CPU time allowance.
Count imported texture data when testing a resource-size explanation.
Compare actual pixel counts for a proposed resolution change.
Describe allocated particle buffers from explicit layout measurements.
Record representative performance and visual regression results.
Loading your checklist…
Unity documents collecting performance data from the release platform rather than relying only on editor behavior. Record the target, build and collection settings used for your comparison.
Keep the same workload when comparing a focused change.
| Item | Record |
|---|---|
| Run identity | Build, device, scene, input sequence and quality settings |
| Measurement | Relevant frames, timings, allocations or I/O observations |
| Intervention | One changed cause and its revision |
| Outcome | Acceptance result, visible quality, tradeoff and regression coverage |
A reciprocal FPS conversion supplies one interval. It does not reveal a frame-time distribution, input latency or the interaction of CPU and GPU work.
A low draw-call count is not a success criterion when the actual bottleneck is elsewhere.
Compare the frames players notice as well as aggregate measurements.