🎮 Unity & C#

Unity mobile performance: the checks worth running before you optimise anything

AA Plus Games Studio·13 days ago·0 replies
CommunityUnity & C# › Unity mobile performance: the checks worth running before you optimise anything
Before you start deleting objects and lowering textures, find out what is actually slow. Most mobile performance work we see is guesswork aimed at the wrong thing.

Establish where you are bound first. Profile on a real mid-range device, never in the editor and never only on a flagship. Then ask: is the CPU waiting on the GPU, or the other way round?

If you are CPU bound, the usual causes are:
- Too many draw calls. Check the batching stats. Objects only batch if they share a material, so twelve materials that could be one atlas is twelve times the cost.
- Work in Update that does not need to run every frame. AI, distance checks and UI refreshes rarely need 60 Hz.
- Garbage collection spikes. Allocating in a hot loop, string concatenation per frame, LINQ in Update.
- Physics running at a higher fixed timestep than the game needs.

If you are GPU bound:
- Overdraw, especially transparent particles and full-screen UI layers stacked on each other. This is the number one killer on mobile.
- Texture compression. Use ASTC on mobile. Uncompressed or wrongly compressed textures cost memory bandwidth and load time.
- Real-time shadows and per-pixel lights. Bake what does not move.
- Post-processing that was designed for a desktop GPU.

Two things worth doing on every project regardless: turn on incremental GC, and put a frame-time counter on screen during development so a regression is noticed the day it lands rather than a month later.

What device are you targeting, and what is your current frame time? Post the profiler numbers and we can be more specific.

0 replies

No replies yet. If you know this one, you are exactly who they need.

Add a reply

Sign in with a free account to reply.