Optimizing Pattern Overhead in Unity

In this lesson, you will learn how to identify and mitigate the hidden memory and CPU costs inherent in complex design patterns by implementing object pooling.

Design patterns like the Command Pattern or Strategy Pattern are fantastic for decoupling your architecture, but they often rely on frequent object instantiation. For instance, if you use a Command object every time a player inputs a move, or a new State object for every minor AI behavior change, you trigger constant memory allocation. This forces the C# Garbage Collector (GC) to work overtime, leading to those dreaded frame-rate stutters during intense gameplay.

To optimize this, we shift from "create-on-demand" to Object Pooling. Instead of destroying objects and letting the GC clean them up, we recycle them.

Implementing an Object Pool for Commands

If you have a MoveCommand used in your input buffer, don't instantiate it with new. Create a simple pool that caches them:

public class CommandPool {
    private Stack<MoveCommand> _pool = new Stack<MoveCommand>();

    public MoveCommand Get() {
        return _pool.Count > 0 ? _pool.Pop() : new MoveCommand();
    }

    public void Return(MoveCommand command) {
        command.Reset(); // Clear data before storing
        _pool.Push(command);
    }
}

By reusing the MoveCommand objects, you eliminate the heap allocations that occur every time a user triggers an action.

Performance Considerations

When applying this to your State Machine or Strategy systems, keep these three rules in mind:

1. Reset State: Always implement an IResettable interface to clear variables when an object returns to the pool; otherwise, you’ll carry "stale" data into the next operation.
2. Growth Limits: Ensure your pools have a cap or a "growth strategy" to prevent them from consuming too much memory in a single frame.
3. Target High Frequency: You don't need to pool everything. Only apply this to systems that run dozens of times per frame or every single frame, such as projectiles, input commands, or particle triggers.

Key Takeaway: Architectural patterns provide structure, but excessive allocation turns that structure into a GC liability; use object pooling to decouple your code while keeping your heap footprint flat.