Are Your Unity Games Still Choking on GC? Master Zero-Allocation Patterns

Introduction

In the demanding world of game development, consistent performance is paramount. Few things disrupt the smooth flow of a Unity game more dramatically than the dreaded garbage collector (GC) spike, manifesting as momentary freezes or dropped frames. The new keyword, while innocuous in many programming contexts, becomes a silent killer in critical game loops when it leads to transient object allocations on the managed heap. While object pooling is a well-known mitigation, truly elite Unity developers are pushing further, embracing zero-allocation patterns for frequently updated, transient state data. This tutorial will guide you through leveraging readonly struct in conjunction with the in keyword to achieve predictable, stable performance by eliminating unnecessary GC pressure and improving cache locality.

The Problem with Classes and Boxing

Every time you instantiate a class in C#, memory is allocated on the managed heap. When this object is no longer referenced, it becomes eligible for garbage collection, potentially triggering a GC pass at an inconvenient time. Even passing value types (like structs) as object parameters, or assigning them to object references, can cause “boxing” – where the struct is wrapped in a heap-allocated object, leading to the same GC issues. Unity’s Vector3 and Quaternion are structs for a reason: they are small, frequently used, and benefit immensely from stack allocation and value semantics. We need to extend this wisdom to our own game data.

The Zero-Allocation Solution: readonly struct and in

The core of our zero-allocation strategy revolves around two powerful C# features:

  1. readonly struct: Unlike classes, structs are value types typically allocated on the stack (for local variables) or inline within their containing object (for fields). This means no separate heap allocation and no GC involvement for their lifecycle. By declaring a struct as readonly, you enforce immutability: all its fields must be readonly, and its properties must only have get accessors. This provides thread safety, prevents accidental modification, and can even enable certain compiler optimizations.

  2. in Keyword for Parameters: When you pass a struct to a method by value, a copy of the entire struct is made. For larger structs, this copying can introduce its own performance overhead. The in keyword allows you to pass a struct by reference, preventing the copy, while still enforcing immutability within the method (you cannot modify the referenced struct). This avoids both heap allocations (like class parameters) and unnecessary value copying (like typical struct parameters), offering the best of both worlds. It essentially gives you a readonly reference to the original struct.

Code Layout/Walkthrough

Let’s consider a common game scenario: passing dynamic movement or state information between components every frame.

Before (Conceptual Problem):

// If this were a class, every frame an allocation would occur.
// Even if it's a struct passed by value, a copy happens.
public class MovementSystem
{
    // ...
    public void UpdateAgentPosition(AgentState state) // If AgentState were a class
    {
        // modify state, potentially reading from it
    }
}

After (Zero-Allocation Pattern):

First, define your transient data as a readonly struct.

using UnityEngine;

// Define an immutable struct to hold transient movement data
public readonly struct AgentMovementData
{
    public readonly Vector3 TargetPosition;
    public readonly float Speed;
    public readonly Quaternion TargetRotation;

    public AgentMovementData(Vector3 targetPos, float speed, Quaternion targetRot)
    {
        TargetPosition = targetPos;
        Speed = speed;
        TargetRotation = targetRot;
    }

    // Example of a helper method, also immutable
    public AgentMovementData WithNewTargetPosition(Vector3 newPos)
    {
        return new AgentMovementData(newPos, Speed, TargetRotation);
    }
}

Next, use this readonly struct with the in keyword for method parameters in your critical loops:

using UnityEngine;

public class AgentMover : MonoBehaviour
{
    // Assume we get movement data from an AI or input system
    // This method is called frequently, e.g., in Update() or FixedUpdate()
    public void ApplyMovement(in AgentMovementData data)
    {
        // Accessing data fields directly
        transform.position = Vector3.MoveTowards(transform.position, data.TargetPosition, data.Speed * Time.deltaTime);
        transform.rotation = Quaternion.RotateTowards(transform.rotation, data.TargetRotation, data.Speed * Time.deltaTime);
        
        // Example: If you needed to modify the data and pass it on,
        // you'd create a *new* struct based on the old one.
        // AgentMovementData newData = data.WithNewTargetPosition(new Vector3(10, 0, 0));
        // SomeOtherMethod(in newData);
    }

    // Example usage in an Update loop
    void Update()
    {
        // Create an AgentMovementData struct.
        // This is allocated on the stack (or as part of the containing object),
        // not the heap, and has no GC overhead.
        AgentMovementData currentMovement = new AgentMovementData(
            targetPosition: GetCurrentTargetPosition(), 
            speed: 5f, 
            targetRotation: GetCurrentTargetRotation()
        );

        // Pass the struct by readonly reference using 'in'.
        // No copy of the struct is made, and no heap allocation occurs.
        ApplyMovement(in currentMovement);
    }

    // Dummy methods for demonstration
    private Vector3 GetCurrentTargetPosition() => new Vector3(Mathf.Sin(Time.time) * 5, 0, Mathf.Cos(Time.time) * 5);
    private Quaternion GetCurrentTargetRotation() => Quaternion.LookRotation(GetCurrentTargetPosition() - transform.position);
}

In this example, AgentMovementData is created on the stack within Update(). When ApplyMovement is called, the in keyword ensures that the struct is passed by reference, avoiding any copying or boxing. This pattern completely eliminates transient heap allocations for this data, removing a significant source of GC pressure.

Conclusion

Embracing readonly struct with the in keyword for transient data in your critical game loops is a paradigm shift towards truly performant Unity development. It’s not just about reducing GC; it’s about optimizing memory access through improved cache locality and establishing a pattern of predictable, stable framerates. By consciously designing your data structures to be value-based and immutable where appropriate, you can eliminate an entire class of performance bottlenecks that plague many Unity projects. Stop wasting cycles, start engineering. Your players (and your profiler) will thank you.