Discussion :

[Metafire18]

Bonjour à tous,

Je travaille actuellement sur un jeu de rôle où l'optimisation de la vitesse d'exécution est une des priorités.
N'ayant rien trouver à ce sujet après plusieurs recherches, je pose la question suivante :
Peut on dire que le paradigme impératif (+procédural) génère des programmes plus rapides que des homologues orienté objet?
Je précise que pour ce projet, le choix du PHP a été fait (Bien que Java me semblerait plus adapté mais là n'est pas le débat )
Je vous remercie d'avance pour l'attention que vous porterez à ce message.

[souviron34]

bonjour



Il y a d'innombrables posts sur ce sujet...

A priori il n'y a pas de différences de vitesse dans un paradigme plutôt que dans un autre...

Dans une implémentation vis-à-vis d'une autre, oui, dans un langage compilé par rapport à un non-compilé, oui..


Le seul élément du "paradigme" objet qui peut ralentir est le "new", qui impose allocation mémoire et initialisation au cas par cas, alors qu'en procédural (mais on peut également le faire en objet) on peut grouper en allouant une seule fois (par xemple un tableau).. et que l'on peut, si on le souhaite, éviter des initialisations quand on juge que ce n'est pas nécessaire...

[Metafire18]

Je te remercie pour ta réponse.

Au passage, j'ai précisé avoir fait plusieurs recherches avec notamment les mots clefs "paradigme", "rapidité", "vitesse", "orienté objet" et "impératif" et je n'ai eu aucun résultat pértinent .

Un anonyme avance l'argument suivant pour soutenir le fait que la POO avec PHP a tendance à diminuer les performances :

Tout d'abord, PHP, contrairement à Java ou C++, n'est pas un langage compilé, mais interprété. Ce qui veut dire qu'à chaque fois qu'on fait appel à un objet, PHP doit inclure la classe, la parcourir, la valider, la compiler en cache à la volée puis enfin créer l'objet.

Qu'en pensez vous?

[gangsoleil]

Bonjour,

Java n'est pas compile non plus : son bytecode est interprete par la machine virtuelle. Mais il est vrai que certaines machines virtuelles specifiques compilent le code dynamiquement afin de rendre son execution plus rapide.

Dans la plus grande majorite des cas, oui un programme ecrit dans un langage compile sera plus rapide que le meme programme ecrit dans un langage interprete.

Si vous avez besoin de performances, pourquoi ne pas passer la partie critique en C ou en C++, et laisser le reste en php ?

[Metafire18]

Merci pour ces précisions.

A vrai dire, la question est plutôt "Doit on limiter la présence de l'OO au minimum dans notre jeu PHP pour augmenter ses performances?"

[souviron34]

combien de fois faut-il répéter ??

Ce n'est pas "limiter l'OO", qui ne veut rien dire, ce serait plutôt "limiter la partie en langage interprété" ...

[Metafire18]

En quoi la phrase "Limiter la présence de l'OO' est absurde?

On peut parfaitement coder tout un jeu de rôle PHP sans avoir recours à l'OO et inversement...

combien de fois faut-il répéter ??

Des liens ou même une explication seraient toute aussi parlant que votre saute d'humeur

[Mac LAK]

Pour optimiser un code en changeant son paradigme, encore faut-il savoir ce qu'il se passe derrière le capot... Peu de gens le savent sur des langages compilés natifs comme du C ou du C++, et sur des langages interprétés, c'est encore bien plus flou en général !

Passer 25 paramètres à une méthode, virtuelle ou non, compilée ou non, sera toujours plus lent que de passer l'adresse d'une structure avec les 25 champs dedans, c'est une question de temps pris par le passage proprement dit des paramètres. Encore faut-il que le langage admette un concept d'adresse / référence...

Or, la différence de performance entre deux paradigmes du même langage ne peut être causée QUE par la différence de temps pris pour passer les paramètres et/ou les indirections de type VMT causées par les objets polymorphes. Bref, à part sur des fonctions critiques appelées extrêmement souvent, tu vas gratter des pécadilles en général... Pour un coût de modification de code qui sera donc disproportionné par rapport au gain final.

L'optimisation gagnée par une compilation du PHP sera des centaines de fois plus importante que la modification du paradigme... Sauf peut-être sur une fonction critique de ton jeu, mais est-ce que ça a seulement un sens en PHP ? As-tu par exemple une boucle de jeu appelée chaque milliseconde ? Ou des milliers d'entités de jeu à modifier à chaque itération du moteur ? Bref, dois-tu assurer un "temps réel" quelconque ?

Si oui, il vaudrait bien mieux câbler la fonction au sein d'une DLL/SO native ajoutée au langage PHP : là, par contre, tu auras un gain fulgurant... Mais tu ne seras plus en PHP "pur".

[Metafire18]

Sauf peut-être sur une fonction critique de ton jeu, mais est-ce que ça a seulement un sens en PHP ? As-tu par exemple une boucle de jeu appelée chaque milliseconde ? Ou des milliers d'entités de jeu à modifier à chaque itération du moteur ?

A vrai dire, nous développons un MMORPG. Je pense pouvoir répondre oui à cette question

[Mac LAK]

A vrai dire, nous développons un MMORPG. Je pense pouvoir répondre oui à cette question

Tout dépend de ce que l'on appelle MMORPG... Un jeu en ligne comme BiteFight est censé entrer dans cette catégorie, et je te garantis pourtant que la charge induite par le système de jeu n'est en rien comparable à ce que l'on a sur un World of Warcraft et autres MMORPG "lourds". Le dimensionnement du serveur est également incomparable entre les deux. Je joue également à des "MMORPG" sur mon iPhone, et là encore, ce n'est pas la puissance serveur et/ou la charge CPU du client qui va poser de gros soucis...

Si vraiment tu as une boucle de MAJ rapide, réellement critique, pour un MMORPG réellement temps réel, alors passes plutôt par Zend (ou autre système équivalent) et une DLL / SO écrite en C/C++... Même si je pense que la gestion de l'affichage devrait largement plus être l'axe d'amélioration.

Dans tous les cas, si tu as réellement un programme aussi lourd que tu le décris, alors PHP est un très mauvais choix de langage quoi qu'il en soit.

[Metafire18]

Je ne pense pas qu'on puisse parler d'un programme lourd à vrai dire puisqu'il s'agit d'un MMORPG par navigateur. Je me demande simplement si le fait de concevoir le jeu en pensant OO peut augmenter les risques d'obtenir un jeu plus lent que dans le cas d'une programmation impérative/fonctionnelle.

[Mac LAK]

Je ne pense pas qu'on puisse parler d'un programme lourd à vrai dire puisqu'il s'agit d'un MMORPG par navigateur. Je me demande simplement si le fait de concevoir le jeu en pensant OO peut augmenter les risques d'obtenir un jeu plus lent que dans le cas d'une programmation impérative/fonctionnelle.

OK. Dans ce cas, je pense sincèrement que tu ferais mieux de t'orienter vers une bonne optimisation des transferts client / serveur (techno type Ajax par exemple) pour ton optimisation, plutôt que d'essayer de gratter des demi-pourcents sur le calcul serveur... Le gros de la charge serveur, ce sera la création des pages vers le client et la réception des actions désirées par le joueur, plutôt que des calculs internes. Surtout que si c'est bien fait, tu devrais avoir des procédures stockées dans ton SGBD qui effectueront les calculs lourds et complexes en lieu et place du PHP.

Il faut également tenir compte du fait que tu n'as pas forcément besoin de faire tourner ton système en permanence : en effet, tu peux aussi te baser sur un fonctionnement de type "machine à états", et dans ce cas, tu ne devras effectuer d'itération du moteur que sur demande. Le reste du temps, ton serveur fait ce qu'il doit faire lorsque personne ne le sollicite : rien...

[Metafire18]

Je te remercie pour ton avis éclairé sur la question