Au cours du développement d'un programme, le développeur doit prendre des décisions en fonction de différentes contraintes.
Un programme informatique est donc un ensemble de compromis.
Ainsi, le programmeur va par exemple choisir entre stocker un résultat en mémoire ou bien le recalculer à la demande, ou bien encore décider d'utiliser de l'assembleur ou le dernier langage objet à la mode.
Chacune de ces décisions vont avoir un impact à la fois sur le développeur et l'ordinateur qui éxécutera le programme.
En effet, vu que rien n'est infini, rien ne se perd, rien ne se crée et tout se transforme, si le développeur choisit d'utiliser moins de mémoire, il va perdre des cycles au niveau du micro-processeur.
Et s'il choisit de privilégier l'utilisation de la mémoire, il va récupérer des cycles, mais il ne pourra plus stocker autant de chose dans la RAM de l'ordinateur.
De même, s'il choisit d'utiliser un langage de bas niveau, tel que l'assembleur, l'ordinateur sera très efficace lorsqu'il éxécutera le programme, ce dernier étant pratiquement dans le langage naturel
de la machine, mais l'effort intellectuel que le développeur devra fournir sera plus long que si un langage à haut niveau d'abstraction est utilisé.
Et donc, à contrario, si le développeur utilise un langage qui lui permet de développer d'une manière naturelle
, l'ordinateur aura un travail beaucoup plus important à fournir lors de l'éxécution du programme, puisque ce dernier devra en quelque sorte être traduit par la machine.
LaurentJ a donc parfaitement raison Lorsqu'il dit qu'un programme qui utiliserait une version complétement objet du langage PHP serait forcément moins efficace que le même programme écrit en langage procédural, voir même avec le modèle objet imparfait de la version actuelle du langage, du point de vue de la machine.
Mais du point de vue humain ?
De ce point de vue, la donne n'est plus la même.
Permettre à un développeur d'utiliser pleinement le modèle objet et la puissance qu'il apporte, via le polymorphisme et la surcharge, lui permettrait d'être plus efficace, plus productif, dans son travail, grâce au haut niveau d'abstraction que ce type de langage autorise à travers l'héritage et la généricité,
L'utilisation de l'objet aurait donc du point de vue humain un impact bénéfique.
La relecture, le test, la maintenance et l'évolutivité d'un code PHP seraient encore facilité et/ou amélioré, autant d'arguments supplémentaires qui permettraient de faire pénétrer PHP un peu plus dans le monde des entreprises ou des langages tel que JAVA régnent en maître.
Alors, est ce que cela vaut vraiment la peine de perdre quelques cycles sur nos micro-processeurs quadri-code à 4 Ghz ?
Personnelement, j'ai fais mon choix il y a longtemps lorsque j'ai découvert les lois de Moore.
Je préfère que la machine me facilite mon travail, pas qu'elle me le complique ou me le rende plus difficile.
Dernier point, en ce qui concerne PHP, son créateur est le premier à dire que si la performance est l'objectif, il ne faut pas l'utiliser pour les traitements lours mais faire appel pour cela à des langages compilés...
2 réactions
1 De Laurentj - 08/11/2008, 01:09
Je suis d'accord avec toi qu'un modèle full objet a son intérêt du point de vue du développeur. Mais :
> Alors, est ce que cela vaut vraiment la peine de perdre quelques cycles sur nos micro-processeurs quadri-code à 4 Ghz ?
Ce n'est pas perdre seulement quelques cycles. C'est plusieurs cycles. Et beaucoup de mémoire. Dans le moteur PHP, une chaine native est stocké dans une structure de 12 octets (sans compter le contenu de la chaine même). Un objet PHP *vide*, sans propriété ni méthode, consomme déjà plus de 1200 octets (et encore, je n'ai pas tout compté, la structure est assez complexe, pas le temps de fouiner plus) et c'est difficile de faire moins, vue le nombre d'informations qu'il faut pour manipuler un objet dans une VM.
Cela veut donc dire qu'une chaine sous forme d'objet native prendrait donc au moins 100 fois plus de place en mémoire qu'une chaine native.
On multiplie ça par le nombre de chaine que l'on manipule dans un script (on va dire jusqu'à quelques dizaines en même temps, peut être même dépassant la centaine vu le nombre d'objet contenant des chaines que l'on manipule sur les grosses appli). Et on multiplie encore par le nombre de script exécuté en même temps sur le serveur...
Bref, tu devineras que la consommation mémoire évolue de manière exponentielle en fonction de la charge serveur. Celui ci s'écroulera donc plus vite avec un PHP qui aurait ses chaines sous forme d'objet natif qu'un serveur avec un PHP actuel. Et cette situation est d'autant plus vrai car plus il y a de la mémoire consommée, plus le gestionnaire de mémoire doit bosser, donc consomme d'autant plus de cycle CPU. Et il faut aussi compter que, comme la structure d'un objet PHP est plus complexe à manipuler qu'une simple chaîne native, alors l'accès à une propriété consomme aussi plus de cycle, etc, etc, etc..
Bref, comme tu vois, avoir des objets natifs ça a un cout, qui peut devenir énorme lorsque qu'il s'agit de sites à plusieurs centaines de milliers ou de millions de hits par jour, car il faudrait investir sur des machines plus grosses, et plus régulièrement à cause du nombre de visiteurs augmentant sans cess (ce qui induit aussi des coûts de maintenance et de fonctionnement plus important).
Maintenant tu vas me dire que tout le monde n'a pas de site à plusieurs millions de hits. Oui mais la majorité se retrouvent dans un cas similaire, car ils sont hébergés sur des serveurs mutualisés, donc qui contiennent des dizaines et des dizaines de sites, serveurs donc bien souvent chargés, comme un site à plusieurs millions de hits. D'où un phénomène similaire : le serveur doit executé des dizaines de scripts PHP en même temps qui eux même manipulent des dizaines et des dizaines de chaînes en même temps..
Si PHP est installé chez la quasi totalité des hébergeurs, ce n'est pas un hasard : il permet de faire des sites dynamiques tout en consommant des ressources de manière raisonnable (à complexité de code équivalente par rapport à d'autres langage web). Si JAVA n'est pas installé chez la quasi totalité des hébergeurs, ce n'est pas un hasard non plus
Se reposer sur le fait qu'on a des machines de plus en plus puissantes est un mauvais choix, car le nombre d'internautes ne fait qu'augmenter dans le monde, le nombre de connexion entre machines aussi (ex service web entre serveurs, agregateurs toujours plus nombreux etc).. Certes il y a aussi des systèmes de caches qui peuvent venir soulager les machines, mais ce n'est que repousser le problème.
Pour conclure, je dirais qu'il y a un choix pragmatique dans l'utilisation de chaine simple plutôt que de chaine objet
>il ne faut pas l'utiliser pour les traitements lours mais faire appel pour cela à des langages compilés...
Ouai enfin là, ça complique le travail du développeur, donc en contradiction avec ce que tu souhaites
2 De Laurentj - 08/11/2008, 01:28
Pardon, petite correction par rapport à mon dernier commentaire : c'est pas 1200, mais environ 400 octets pour l'occupation mémoire d' un objet vide sans propriété. 1200 c'est l'occupation mémoire d'un zend_class_entry, qui contient donc les informations d'une classe, qui ne sont donc pas dupliqué pour chaque instance de cette classe (les objets).
Cependant, mon discours reste encore valable