Empreinte mémoire réduite

Avant tout, la raison principale de l'implémentation du mécanisme de collecte des déchets est la réduction de la mémoire consommée, en nettoyant les références circulaires lorsque les conditions requises sont remplies. Avec PHP, ceci arrive dès que le tampon de racines est plein, ou lorsque la fonction gc_collect_cycles() est appelée. Sur le graphe ci-après, nous affichons l'utilisation mémoire du script suivant, avec PHP 5.2 et avec PHP 5.3, en excluant la mémoire obligatoire que PHP consomme pour lui-même au démarrage.

Exemple #1 Exemple d'utilisation mémoire

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

$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";
	}
}
?>

Dans cet exemple quelque peu accadémique, nous créons un objet possédant un attribut le référençant lui-même. Lorsque la variable $a dans le script est réassignée à l'itération suivante, une fuite mémoire apparaitra. Dans ce cas, les deux conteneurs zval fuient (la zval de l'objet et celle de l'attribut), mais une seule racine possible est trouvée : la variable qui a été supprimée. Lorsque le tampon de racines est plein après 10.000 itérations (avec un total de 10.000 racines possibles), le mécanisme de collecte des déchets entre en jeu et libère la mémoire associée à ces racines probables. Cela se voit très clairement sur les graphes d'utilisation mémoire de PHP 5.3. Après chaque 10.000 itérations, le mécanisme se déclenche et libère la mémoire associée aux variables circulairement référencées. Le mécanisme en question n'a pas énormément de travail dans cet exemple, parce que la structure qui a fuit est extrêmement simple. Le diagramme montre que l'utilisation maximale de mémoire de PHP 5.3 est d'environ 9Mo, là où elle n'arrête pas d'augmenter avec PHP 5.2.

Ralentissements durant l'exécution

Le second point où le mécanisme de collecte des déchets (GC) affecte les performances est lorsqu'il est exécuté pour libérer la mémoire "gaspillée". Pour quantifier cet impact, nous modifions légérement le script précédent afin d'avoir un nombre d'itérations plus élevé et de supprimer la collecte de l'usage mémoire intermédiaire. Le second script est reproduit ci-dessous :

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

for ( $i = 0; $i <= 1000000; $i++ )
{
	$a = new Foo;
	$a->self = $a;
}

echo memory_get_peak_usage(), "\n";
?>

Nous allons lancer ce script 2 fois, une fois avec zend.enable_gc à on, et une fois à off:

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

Sur ma machine, la première commande semble durer tout le temps 10,7 secondes, alors que la seconde commande prend environ 11,4 secondes. Cela correspond à un ralentissement de 7% environ. Cependant, la quantité totale de mémoire utilisée par le script est réduite de 98%, passant de 931Mo à 10Mo. Ce benchmark n'est pas très scientifique ou même représentatif d'applications réelles, mais il démontre concrètement en quoi le mécanisme de collecte des déchets peut être utile au niveau de la consommation mémoire. Le bon point est que le ralentissement est toujours de 7%, dans le cas particulier de ce script, alors que la mémoire préservée sera de plus en plus importante au fur et à mesure que des références circulaires apparaitront durant l'éxécution.

Statistiques internes du GC de PHP

Il est possible d'obtenir quelques informations supplémentaires concernant le mécanisme de collecte des déchets interne à PHP. Mais pour cela, il vous faut recompiler PHP avec le support du benchmarking et de la collecte de données. Vous devrez renseigner la variable d'environnement CFLAGS avec -DGC_BENCH=1 avant de lancer ./configure avec les options qui vous intéressent. L'exemple suivant démontre cela :

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

Lorsque vous ré-éxécutez le code du script ci-dessus avec le binaire PHP fraichement reconstruit, vous devriez voir le résultat suivant après l'exécution :

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

Les statistiques les plus intéressantes sont affichées dans le premier bloc. Vous voyez ici que le mécanisme de collecte des déchets a été déclenché 110 fois, et qu'au total ce sont plus de 2 millions d'allocations mémoire qui ont été libérées durant ces 110 passages. Dès lors que le mécanisme est intervenu au moins une fois, le pic du buffer racine est toujours de 10000.

Conclusion

De manière générale, la collecte des déchets de PHP ne causera un ralentissement que lorsque l'algorithme de collecte de cycles tournera, ce qui signifie que dans les scripts normaux (plus courts), il ne devrait pas du tout y avoir d'impact sur les performances.

Cependant, lorsque le mécanisme de collecte de cycles sera déclenché dans des scripts normaux, la réduction de l'empreinte mémoire permettra l'exécution parallèle d'un nombre plus important de ces scripts, puisque moins de mémoire sera utilisée au total.

Les avantages se sentent plus nettement dans le cas de scripts démons ou devant tourner longtemps. Ainsi, pour les applications » PHP-GTK qui tournent souvent plus longtemps que des scripts pour le Web, le nouveau mécanisme devrait réduire significativement les fuites mémoire sur le long terme.