Gestion de la mémoire avec PHP

Aujourd’hui, Frédéric Hardy aka mageekguy a posté un article en ce qui concerne la gestion de la mémoire en php. Cet article se veut une réaction à celui-ci qui explique en regardant au sein du code source de php comment le langage gère la mémoire.

Si je reviens sur ces deux articles c’est que l’article original m’a un peu laissé sur ma faim et que le second m’a quand même choqué. Je n’ai peut être pas l’expertise ni l’aura de Frédéric Hardy, mais je n’arrive pas à me retrouver dans sa sentence : “idiot”.

Je ne reviendrais pas sur les arguments de ceux qui sont pour ou qui sont contre cet assassinat éditorial, mais je me concentrerai un peu sur la technique.Ou du moins ce que j’en connais et ce que ces articles m’ont appris.

Frédéric Hardy a le mérite, malgré ses propos agressifs de donner des exemples techniques et des conseils de bonnes pratique. Pour tous ceux qu’il cite, je les connaissais mais je croyais que c’était plus de la bidouille très geek de la part de quelqu’un qui est passionné par php que des pratiques très professionnelles.

En gros il y a deux grands points de “bonne pratique” qui doivent être respectée. La première concerne le code en lui même : utiliser, quand c’est souhaitable la fonction unset, comme par exemple, à la fin d’un foreach, ou bien pour libérer un tableau dont on n’a plus besoin (les tableaux php sont particulièrement lourds !).

D’ailleurs, c’est bien ça qui me fait dire que l’avis de Frédéric Hardy est trop totalitaire.
Comment savoir que l’usage de unset est souhaitable si on se fie simplement à l’instinct? On pourrait se dire que c’est clair qu’un tableau c’est plus lourd qu’un simple entier et donc que c’est là que ça devient utile. Oui mais non. En C une chaîne de caractères, c’est un tableau de caractères. Imaginons qu’on utilise une norme particulièrement gourmande en taille telle que UTF-32 pour représenter un caractère. Une chaîne UTF-32 prend donc autant de place qu’un tableau de int.
A l’opposé, en php faire un tableau de caractère ou une chaîne de caractère ce n’est pas pareil, même si l’opérateur crochet a été surchargé pour les strings. Ainsi même un simple array(‘a’); prendra plus de place que la chaîne de caractère “francoisdambrine.olympe.in”.

Autre exemple de code : les requêtes non bufferisées.
J’avais plus ou moins conscience de ce que c’était, mais je continuais quand même d’utiliser à tout va des fetchAll par pure facilité en m’assurant juste que ma requête ne prenait pas trop de résultat. En fait il semblerait que cette pratique sans être particulièrement mauvaise devrait être bien moins systématique.

Ensuite, le conseil de mageekguy : laisser aller ou bien utilisez un autre langage.

Par contre, des optimisations peuvent être amenées via l’environnement. Et là les deux le disent, c’est juste la forme qui change. C’est pourquoi je ne comprends pas que mageekguy soit si agressif : cache d’opcode, utilisation de la dernière version de php, tous les deux le disent.
Petite astuce apparemment utilisée en milieu professionnel et aussi par le geek que je suis : compilez vous même les versions de php. Cela permet de réduire grandement l’usage de mémoire.

Et en ce qui concerne l’Opcode, une bonne nouvelle a été annoncée sur la liste de diffusion de php il y a peu : ZendOptimiser+ va passer open source et est candidat pour être le moteur de cache par défaut de php. Si un tel moteur manque dans le coeur de php de manière évidente, ZO+ a l’avantage d’optimiser la compilation en opcode améliorant ainsi les dernières avancées de php 5.4 et 5.5.

 

Leave a Reply

Your email address will not be published. Required fields are marked *