Object Pooling

Hace un tiempito estaba haciendo un juego en Flash, en el cual iban apareciendo enemigos cada vez en mayor cantidad y llegaba un momento en que la perdida de rendimiento era muy fuerte.

Una solución (o al menos un enfoque para mejorar la situación) a este tipo de situaciones es lo que se conoce como Object Pooling.

El término pool significa literalmente pileta, pero para conceptos como este, no se me ocurre una traducción correcta, pero basicamente hace referencia a un conjunto de recursos a los que se puede acceder para ser usados en algo (se usa no solo en la informática).

Object Pooling es un Design Pattern en concepto muy simple. Se trata de mantener un pool de objectos constantemente instanciados e ir accediendo a ellos según los necesitemos en vez de ir instanciandolos y disposiandolos de memoria on demand. Cada vez que accedemos a un objeto, sin duda, necesitamos resetearlo, así que que también hay que «limpiar» los objetos una vez liberados.

¿Cuándo usar Object Pooling?

La idea de object pooling es ahorrar memoria y tiempo de cpu en la instanciación y liberación de objetos, además de prevenir memory leaks y la fluctuante situación del garbage collector (supiendo que usemos un lenguaje que lo tenga). Por lo tanto, esta técnica es ideal para cuando instanciamos mucho una clase  y/o el costo de instanciación es muy alto.

Tomemos el ejemplo de un survival mini game. Si, de esos que empiezan a venir chobis y chobis y chobis. Digamos, zombies (todos amamos los zombies). Con el paso del tiempo, la cantidad de zombies es cada vez más grande.

Bien, acá tenemos  un buen caso para usar (casi seguro) Object Pooling.

Vamos a usar ActionScript3 para los ejemplos. Y el objecto  que vamos a poolear es,claramente, un Zombie.

Zombie.as

public class Zombie extends Sprite{
        public static const OUT_SCREEN_X   : Number  = -2000;
        public static const OUT_SCREEN_Y   : Number  = -2000;
        // -- Class Constructor
        public function Zombie(){
        }
        public function reset():void{
             this.x=OUT_SCREEN_X;
             this.y=OUT_SCREEN_Y;
        }
}

Como vemos,es una clase muy básica. Simplemente estamos hablando de herencia de Sprite. Ahora nos ocuparemos del pool:

ZombiePool.as

public class ZombiePool {
        public static const MIN_ZOMBIE_QTY    : int  = 50;
        private m_pool : Vector.<Zombie>;
        public function ZombiePool(){
            m_pool = new Vector.<Zombie>();
            var i:int =MIN_ZOMBIE_QTY   ;
            while (i-->0){
                m_pool.push(new Zombie());
            }
        }
        public function getAZombie():Zombie{
              if(m_pool.length==0)
                   m_pool.push(new Zombie());
              return (m_pool.pop()).reset();
        }
        public function freeZombie(_zombie:Zombie):void{
                m_pool.push(_zombie);
       }
}

Revisemos rapidamente el código. Como podemos ver,  la pool propiamente dicha es un Vector de Zombies. Esta pileta es inicializada con cierta cantidad de zombies definida en la constante MIN_ZOMBIE_QTY. Por supuesto que podria haber sido inicializada por inyección en el constructor o
seteada en algun init del ZombiePool, es indistinto.
Entonces, el uso es sumamente simple. Cuando un cliente (por ejemplo.. una clase Level, o GameManager
o Map,etc) necesite crear un zombie, en lugar del clásico

var zombie:Zombie = new Zombie();

deberá utilizar:

var zombie:Zombie = ZombiePool.getAZombie();

Tras eso, lo inicializa como desee, siempre que el zombie tenga un metodo para inicializar
e inyectar valores o bien estos sean públicos.
De esta manera evitamos crear y eliminar de memoria constantemente (y esto, en un juego como este,
puede ser muy constantemente) Zombies, evitamos el mal uso del garbage collector, memory leaks
y el costo de una instanciación.
En este ejemplo simple usamos un pool incremental, es decir, si la pool se encuentra vacía,
automaticamente crece. Existen otros enfoques (pool limitada, pool que empieza vacía, etc),
pero son básicamente lo mismo.

Cuando no Usarlo , el Anti-Pattern
Aunque no me pasó, existen casos donde aparentemente es copado usar Object Pooling pero,
la realidad, termina siendo muy distinta (lo que se conoce como Anti-Pattern, es decir,
usar un patrón creyendo que es la mejor solución pero que termine teniendo un efecto contraproducente.)
Se trata de casos en los que limpiar el objecto (resetearlo) es más costoso que instanciarlo
o casos donde las referencias al objecto del pool pueden ser conflictivas y al liberarlo
al pool puede generarse problemas con los punteros y demás. Pero no creo que sea para
alarmarse, la mayoría de los mortales no tenemos ese problema.

Así que, a llenarse de zombies!