Optimization Best Practices

How professional teams approach performance: set budgets, measure on real hardware, find whether you're CPU- or GPU-bound, fix the biggest problem first, and keep it from coming back. This page covers the process and the engine-level settings. For script-level tips, see Optimizing Your Code.

1. Decide your targets early

Performance is much cheaper to plan for than to fix at the end. Before production, write down:

Aim below the limit. A game that takes exactly 16.6 ms per frame drops frames whenever anything extra happens. Leave headroom for spikes like explosions and loading.

2. Profile on the target hardware

• The Editor is slower and behaves differently than a build. Make a Development Build with Autoconnect Profiler and profile the real device.
• Profile the weakest device you support, not your development PC.
• On mobile, test for 20-30 minutes. Phones get hot and thermal throttling lowers CPU/GPU speed, so a game that runs well for 2 minutes may not at minute 15.
• Profile the heaviest moments (big fights, busy areas), not an empty test scene.

3. Find out what's limiting you

Fixing the wrong side wastes time. Figure out what you're bound by first:

4. Measure, change one thing, measure again

1. Record a baseline in a repeatable situation (same scene, same camera path).
2. Change one thing.
3. Record again and compare (the Profile Analyzer is ideal).
4. Keep it only if it helped. Write down what you changed and the result.

Add your own markers so your systems show up clearly in the Profiler:

using Unity.Profiling;
using UnityEngine;

public class EnemyAI : MonoBehaviour
{
    private static readonly ProfilerMarker ThinkMarker = new ProfilerMarker("EnemyAI.Think");

    void Update()
    {
        using (ThinkMarker.Auto())   // everything in this block is timed under "EnemyAI.Think"
        {
            Think();
        }
    }

    void Think() { /* ... */ }
}

5. Architecture choices that scale

• Event-driven over polling. React when something changes instead of checking every frame.
• Do less, less often. AI doesn't need to think 60 times a second; far-away objects don't need full updates. See Update & FixedUpdate for staggering.
• Pool frequently spawned objects. See Object Pooling.
• Data-oriented code for big numbers. Thousands of units? Store data in arrays of structs and process them in tight loops. Unity's C# Job System spreads work over CPU cores, and the Burst compiler turns that code into highly optimized machine code. For very large simulations, Unity's Entities (ECS) package is built around this.
• Draw without GameObjects where possible (see GPU Instancing).
• Spread spikes over frames ("time slicing"): generate a level chunk per frame rather than everything in one frame, and load scenes asynchronously.

6. Assets and memory

7. Engine and build settings

• Incremental GC (Player Settings, on by default in recent versions): spreads garbage collection over several frames to avoid big spikes. It doesn't replace reducing allocations.
• IL2CPP scripting backend for release builds: converts C# to C++ for faster code (required on iOS). Combine with Managed Stripping to reduce build size.
• Target frame rate on mobile: mobile platforms default to 30 FPS. Set Application.targetFrameRate = 60; if you want 60, or keep 30 to save battery and heat.
• Physics: set the Layer Collision Matrix, keep Auto Sync Transforms off, and choose the largest fixed timestep that still feels right.
• Quality levels: provide Low/Medium/High presets (shadow distance, render scale, post-processing) and pick a default per device.
• Strip logs from release builds, and don't ship Development Builds.

8. Keep it fast

• Profile regularly, not just before release. A weekly check catches problems while it's still obvious which change caused them.
• Automate: the Performance Testing package (com.unity.test-framework.performance) can record timings in tests, so a CI build can flag regressions.
• Performance is part of "done". A feature that breaks the frame budget isn't finished.
• Don't micro-optimize blindly. Readable code that's fast enough beats clever code that's slightly faster. Optimize what the Profiler points at.

Checklist

1. Targets and budgets written down per platform.
2. Profiled a development build on the minimum-spec device, including a long session.
3. Know whether you're CPU-bound (which part?) or GPU-bound.
4. No per-frame GC allocations in gameplay.
5. Frequently spawned objects are pooled.
6. Draw calls checked in the Frame Debugger; materials shared; instancing where it helps.
7. Texture, audio and mesh import settings reviewed.
8. Release build: IL2CPP, no dev logs, correct target frame rate.

See also

• Optimizing Your Code
• GPU Instancing & Batching
• Object Pooling
• Working with Update & FixedUpdate

This page is a simplified, AI-assisted interpretation. For the complete and authoritative reference, see the official Unity documentation.