Considerations sur les performances
Nous avons déja vu dans les sections précédentes que la collecte des racines probables avait un impact très léger sur les performances, mais c'est lorsque l'on compare PHP 5.2 à PHP 5.3. Même si l'enregistrement des racines probables est plus lent que de ne pas les enregistrer du tout, comme dans PHP 5.2, d'autres améliorations apportées par PHP 5.3 font que cette opération ne se ressent pas au niveau des performances.
Il y a principalement deux niveaux pour lesquels les performances sont affectées. Le premier est l'empreinte mémoire réduite, et le second est le délai à l'exécution, lorsque le mécanisme de nettoyage effectue son opération de libération de mémoire. Nous allons étudier ces deux axes.
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.14159265359';
}
$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 acadé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 :
Exemple #2 Impact de GC sur les performances
<?php
class Foo
{
public $var = '3.14159265359';
}
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:
Exemple #3 Lancement du script ci-dessus
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 :
Exemple #4 Recompiler PHP pour activer le support du benchmark du GC
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 :
Exemple #5 Statistiques GC
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.