Optimisation without measurement is guesswork, and the guesses are usually wrong — the intuitive culprit is rarely the actual one.
CPU or GPU
The first question. If the CPU is the bottleneck, reducing polygons achieves nothing. If the GPU is, reducing draw calls achieves little.
Every engine profiler reports both. Find which one the frame is waiting on before touching anything.
Common CPU bottlenecks
- Draw call submission
- Physics
- Animation evaluation, particularly many skinned meshes
- Garbage collection
- Game logic
Common GPU bottlenecks
- Overdraw, usually transparency
- Shader complexity
- Texture bandwidth
- Shadow map rendering, which is often a much larger share than people expect
- Post-processing
Measure the right frame
Average frame time hides the problem. A game at sixty frames per second average with periodic drops to twenty feels bad, and the average says it is fine. Look at worst-case frames and at frame time consistency.
Change one thing
Optimise one thing, measure, keep or revert. Batched changes make it impossible to know what helped, and some optimisations trade one cost for another — merging meshes reduces draw calls and increases memory, and whether that is a win depends on which one was binding.
Test on the target
Desktop performance says nothing about mobile. A mid-range phone is the honest test for a mobile title, not a development machine, and thermal throttling means a sustained test differs from a thirty-second one.
For scenes built with generated assets
The likely bottlenecks are predictable: draw calls from many unique materials, and texture memory from many unique textures at default settings. Both are consequences of every asset being unique, and both are addressed by consolidation rather than by reducing geometry.