Deep dive: The design and implementation of object pools

This post first appeared on our blog at Gamelogic.

In software development, particularly in game development and real-time applications, efficient memory management is crucial for maintaining optimal performance. One common technique employed to manage objects efficiently is known as object pooling.

An object pool is a design pattern that pre-allocates a set of objects and keeps them ready for use, rather than creating and destroying objects on the fly. This pool of objects can be reused, significantly reducing the overhead of object creation and garbage collection.

If you are a game programmer, you may have seen the pattern described in Robert Bystrom’s Game Design Patterns. His description and implementation are more relevant to languages such as C++.

Here we look at the design and implementation of pools with a focus on C## and Unity. We will also look at some basic variations, and how the design changes if we require that the onbjects implement an interface. We look at some design techniques that come up in the implementation of pools, and finally, I give what I think is a set of best practices when it comes to the implementation of pools.

The problem

Here is more specifically the problems we can solve with an object pool:

A first implementation

The easiest way to implement an object pool is to use a stack of inactive objects.

{
    inactiveObjects =  Stack<Bat>();

     ( i = ; i < n; i++)
    {
        inactiveObjects.Push( Bat());
    }
}

() => inactiveObjects.// what  the stack is empty
 Release(obj) => inactiveObjects.we will use the pool like this:

() = ()
// Later...

(

This implementation suffers from a few issues:

A stack based pool

 {
     Capacity { get; }
    bool HasAvailableObject { get; }
     InactiveObjectCount { get; }
    ;
    ;
    ;
    ;
}

And here is our stack-based implementation of this interface:

  StackPool<T> : IPool<T>
{
     readonly Stack<T> inactiveObjects = ();
     readonly Func<T> createActive;
     readonly Action<T> activate;
     readonly Action<T> deactivate;
     readonly Action<T> destroy;

      Capacity { get;  set; }
      InactiveObjectCount => inactiveObjects.;
     bool HasAvailableObject => inactiveObjects. > ;

     StackPool(
         capacity,
        Func<T> createActive,
        Action<T> activate,
        Action<T> deactivate,
        Action<T> destroy)
    {
        Capacity = capacity;
        .createActive = createActive;
        .activate = activate;
        .deactivate = deactivate;
        .destroy = destroy;

        CreateActive(capacity);
    }

      CreateActive( capacity)
    {
         ( i = ; i < capacity; i++)
        {
            var newObject = createActive();
            deactivate(newObject);
            inactiveObjects.(newObject);
        }
    }

     T Get()
    {
         (inactiveObjects. == )
        {
              InvalidOperationException();
        }

        var obj = inactiveObjects.();
        activate(obj);
         obj;
    }

      Release(T obj)
    {
        deactivate(obj);
        inactiveObjects.(obj);
    }

      IncreaseCapacity( increment)
    {
        Capacity += increment;
        CreateActive(increment);
    }

      DecreaseCapacity( decrement)
    {
         inactiveDecrement = inactiveObjects. < decrement ? inactiveObjects. : decrement;

         ( i = ; i < inactiveDecrement; i++)
        {
            var obj = inactiveObjects.();
            destroy(obj);
        }

        Capacity -= inactiveDecrement;
         inactiveDecrement;
    }
}

Note the following:

For pool users: how to implement the pool delegates

The pool user needs to supply the pool with four delegates. Here are notes on how these delegates should be implemented.