Huella de memoria reducida

En primer lugar, la razón principal de la implementación del mecanismo de recolección de basura es la reducción de la memoria consumida, limpiando las referencias circulares cuando se cumplen las condiciones requeridas. Con PHP, esto ocurre tan pronto como el búfer de raíces está lleno, o cuando se llama a la función gc_collect_cycles(). En el gráfico a continuación, se muestra el uso de memoria del siguiente script, con PHP 5.2 y con PHP 5.3, excluyendo la memoria obligatoria que PHP consume por sí mismo al inicio.

Ejemplo #1 Ejemplo de uso de memoria

<?php
class Foo
{
public $var = '3.14159265359';
public $self;
}

$baseMemory = memory_get_usage();

for ( $i = 0; $i <= 100000; $i++ )
{
$a = new Foo;
$a->self = $a;
if ( $i % 500 === 0 )
{
echo sprintf( '%8d: ', $i ), memory_get_usage() - $baseMemory, "\n";
}
}
?>

En este ejemplo algo académico, se crea un objeto que tiene un atributo que se referencia a sí mismo. Cuando la variable $a en el script se reasigna a la siguiente iteración, aparecerá una fuga de memoria. En este caso, los dos contenedores zval se fugan (el zval del objeto y el del atributo), pero solo se encuentra una raíz probable: la variable que ha sido eliminada. Cuando el búfer de raíces está lleno después de 10.000 iteraciones (con un total de 10.000 raíces probables), el mecanismo de recolección de basura entra en juego y libera la memoria asociada a estas raíces probables. Esto se ve muy claramente en los gráficos de uso de memoria de PHP 5.3. Después de cada 10.000 iteraciones, el mecanismo se desencadena y libera la memoria asociada a las variables circularmente referenciadas. El mecanismo en cuestión no tiene mucho trabajo en este ejemplo, porque la estructura que se fugó es extremadamente simple. El diagrma muestra que el uso máximo de memoria de PHP 5.3 es de aproximadamente 9Mo, mientras que sigue aumentando con PHP 5.2.

Ralentizaciones durante la ejecución

El segundo punto donde el mecanismo de recolección de basura (GC) afecta el rendimiento es cuando se ejecuta para liberar la memoria "desperdiciada". Para cuantificar este impacto, se modifica ligeramente el script anterior para tener un número de iteraciones más alto y eliminar la recolección del uso de memoria intermedia. El segundo script se reproduce a continuación:

Se lanzará este script 2 veces, una vez con zend.enable_gc en on, y una vez en off:

time php -dzend.enable_gc=0 -dmemory_limit=-1 -n example2.php
# y
time php -dzend.enable_gc=1 -dmemory_limit=-1 -n example2.php

En mi máquina, el primer comando parece durar siempre 10,7 segundos, mientras que el segundo comando tarda aproximadamente 11,4 segundos. Esto corresponde a un retraso de aproximadamente el 7%. Sin embargo, la cantidad total de memoria utilizada por el script se reduce en un 98%, pasando de 931Mo a 10Mo. Este benchmark no es muy científico ni representativo de aplicaciones reales, pero demuestra concretamente en qué medida el mecanismo de recolección de basura puede ser útil en términos de consumo de memoria. El punto positivo es que el retraso es siempre del 7%, en el caso particular de este script, mientras que la memoria preservada será cada vez más importante a medida que aparezcan referencias circulares durante la ejecución.

Estadísticas internas del GC de PHP

Es posible obtener algunas informaciones adicionales concernientes al mecanismo de recolección de basura interno de PHP. Pero para ello, se debe recompilar PHP con el soporte de benchmarking y recolección de datos. Se debe establecer la variable de entorno CFLAGS con -DGC_BENCH=1 antes de lanzar ./configure con las opciones que interesan. El siguiente ejemplo lo demuestra:

export CFLAGS=-DGC_BENCH=1
./config.nice
make clean
make

Cuando se re-ejecuta el código del script anterior con el binario PHP recién reconstruido, se debería ver el siguiente resultado después de la ejecución:

GC Statistics
-------------
Runs:               110
Collected:          2072204
Root buffer length: 0
Root buffer peak:   10000

      Possible            Remove from  Marked
        Root    Buffered     buffer     grey
      --------  --------  -----------  ------
ZVAL   7175487   1491291    1241690   3611871
ZOBJ  28506264   1527980     677581   1025731

Las estadísticas más interesantes se muestran en el primer bloque. Se ve aquí que el mecanismo de recolección de basura se ha desencadenado 110 veces, y que en total son más de 2 millones de asignaciones de memoria las que se han liberado durante estos 110 pasos. Tan pronto como el mecanismo haya intervenido al menos una vez, el pico del búfer de raíces es siempre de 10000.

Conclusión

En general, la recolección de basura de PHP solo causará un retraso cuando el algoritmo de recolección de ciclos se ejecute, lo que significa que en los scripts normales (más cortos), no debería haber ningún impacto en el rendimiento.

Sin embargo, cuando el mecanismo de recolección de ciclos se desencadene en scripts normales, la reducción de la huella de memoria permitirá la ejecución paralela de un número mayor de estos scripts, ya que se utilizará menos memoria en total.

Las ventajas se sienten más claramente en el caso de scripts demonio o que deben ejecutarse durante mucho tiempo. Así, para las aplicaciones » PHP-GTK que a menudo duran más que los scripts web, el nuevo mecanismo debería reducir significativamente las fugas de memoria a largo plazo.