A propos de la POO en PHP

[MyHeadXplod]

La poo en php permet-elle de gagner quelque chose en terme de vitesse d'execution? A ce que j'ai vu pour le moment ça semble surtout utile au niveau de la réutilisabilité et de la clarté du code.

[Sephi-Chan]

En fait il semble qu'on perde un poil de performances. C'est toutefois un moindre mal car la POO facilite la mise au point de systèmes économes, tels que la mise en cache. On peut donc y gagner, au final.


Sephi-Chan

[MyHeadXplod]

Ok merci

[lanoix]

Ben ca dépend si tu considères d'autre facteur...

Mon raisonnement... J'estime coder très bien, aussi bien en PHP5 que PHP4, et être bon en architecture OO (je reprécise que c'est mon métier ca ). Si moi aujourd'hui je démarre un projet en PHP non OO, il sera plus rapide en terme d'exécution (je ne sais pas dans quelle mesure exacte cependant) que le même site en PHP OO. Mais je vais mettre 3 (voir 4 peut-être) fois plus de temps pour le réaliser. Je chercherai 2 fois plus lorsque j'aurai un bug à résoudre. Et il sera plus difficile à un éventuel collaborateur de rentrer dans le projet.
Je choisirais donc l'OO, car j'estime coder de toute manière suffisament bien en OO aussi que pour ne pas "perdre" à mauvais escient des temps d'exécution.

A côté, quelqu'un qui code comme un porc en non OO... Codera de manière moins cochonnée en OO, car cela lui aura demander d'apprendre + de principes de bon utilisation ou un certain degré de compétence. Je prend un exemple concret, un ami qui n'utilisait jamais de jointures dans ses requêtes... (Il en savait pas ce que c'était...) Facile d'imaginer la lenteur d'un site pareil. Avant de pouvoir fait de l'OO il y a de grandes chances pour qu'il aie lu avant cela les jointures en SQL. L'exemple est trop poussé ok, mais c'est dans cet esprit que je vois les choses.

Je penses que si tu codes "moyen" en non OO, apprendre l'OO améliorera ton non-OO... Mais tu devras continuer en non-OO pour garder les mêmes performances d'exécution, voir les améliorer.

[Sephi-Chan]

Je parlais en terme de temps d'exécution. Il a été démontré qu'un script procédural était plus rapide que son équivalent objet, à optimisation égale.

Ensuite il est clair qu'après avoir longtemps été réticent à l'utilisation de l'OO, je trouve ça finalement mieux car plus clair et très naturel.

Je suis toujours contre certaines choses, comme la séparation abusive, l'utilisation de Frameworks dont la majeur partie des fonctionnalités me sont inutiles, etc.


Sephi-Chan

[naholyr]

Un petit test :

Code PHP :

<?php



require_once 'Benchmark/Timer.php';



$benchmark = new Benchmark_Timer();

$benchmark->start();









// Hello World procédural



$benchmark->setMarker('Entrée procédural');



function bonjour($utilisateur)

{

    return 'Bonjour, ' . $utilisateur['nom'];

}



$benchmark->setMarker('Exécution procédural');



for ($n=0; $n<10; $n++) {

    $utilisateur = array('nom' => 'Bob');

    for ($i=0; $i<10000; $i++) {

        bonjour($utilisateur);

    }

    $benchmark->setMarker('Appel x10 000 procédural');

}











// Hello World objet



$benchmark->setMarker('Entrée objet');



class Utilisateur

{



    private $nom;



    function __construct($nom)

    {

        $this->nom = $nom;

    }



    function bonjour()

    {

        return 'Bonjour, ' . $this->nom;

    }



}



$benchmark->setMarker('Exécution objet');



for ($n=0; $n<10; $n++) {

    $utilisateur = new Utilisateur('Bob');

    for ($i=0; $i<10000; $i++) {

        $utilisateur->bonjour();

    }

    $benchmark->setMarker('Appel x10 000 objet');

}



$benchmark->stop();

$benchmark->display(); 

[Loetheri]

Tu utilises souvent une même méthode ou fonction 10.000 fois de suite dans un de tes applications ? Moi, pas ^^ Ou du moins jamais sur la même page.

Ce qu'on pourrait appeler un benchmark, n'est en réalité qu'une illustre bêtise ;-)

PS : Juste pour signaler que ce genre de "test" ne signifie pas grand chose à la base sans oublier qu'aucune spécification n'est donné

[Sephi-Chan]

Alors l'article que j'avais lu était un peu plus pessimiste quant aux performances de l'OO. Les déclaration des classes et celle des fonctions est-elle comprise dans le test ? Peut-être que l'interprétation des classes ralentirai (peut-être est-ce plus "long" qu'une déclaration de fonction) l'exécution.

Toujours est-il que ton test me rassure.


Sephi-Chan

[naholyr]

Je sais que tu n'aimes pas les benchmarks, mais ça permet pourtant d'avoir un minimum de référence, et d'avoir quelque chose de concret sur lequel discuter... C'est mieux que de causer dans le vent non ?

Tu utilises souvent une même méthode ou fonction 10.000 fois de suite dans un de tes applications ? Moi, pas ^^ Ou du moins jamais sur la même page.

PHP n'implémente pas de système de cache de résultat des fonctions. Appeler 10000 fois la même fonction ou 10000 fonctions différentes (mais de corps identique) a le même impact.

Ce qu'on pourrait appeler un benchmark, n'est en réalité qu'une illustre bêtise ;-)

C'est pourtant le test classique réalisé pour comparer le temps d'appel d'une fonction par rapport au temps d'appel d'une méthode d'un objet, je pense qu'il remplit bien son office.
On est bien d'accord : ça ne permet pas par exemple de savoir comme se le demande Sephi si une déclaration de classe avec 20 méthodes est plus long ou plus court qu'une déclaration de 20 fonctions. Je peux vous dire que la différence est du même ordre que pour les appels de fonctions (mais cette fois il faudra me croire sur parole).

La seule cause de perte de perfs, c'est la multiplication des couches. L'utilisation du concept MVC fait perdre des perfs, l'utilisation d'un moteur de templates fait perdre des perfs, l'utilisation d'un objet PHPMailer au lieu d'appeler directement mail() fait perdre des perfs, etc...

On parle bien sûr de PHP5 (en version 4, c'est de la fausse POO, derrière ce ne sont que des tableaux associatifs et des fonctions avec des noms à rallonge qui sont générés, et ça ne peut donc qu'avoir un impact négatif sur les perfs).

[Zamentur]

La seule cause de perte de perfs, c'est la multiplication des couches. L'utilisation du concept MVC fait perdre des perfs, l'utilisation d'un moteur de templates fait perdre des perfs, l'utilisation d'un objet PHPMailer au lieu d'appeler directement mail() fait perdre des perfs, etc...

Théoriquement oui
Dans la pratique c'est pas si sur!

Je veux dire par là que la POO de part le fait qu'elle permet une maintenance beaucoup plus simple, engendre forcement, en plus de la clarté du code qui n'est pas à négliger sur de gros projet, une amélioration des perf due à un code mieux fait car mieux construit

Evidement sur un test benchmark on tient à mettre en place un systeme qui soit quasi identique afin de comparer les 2 systemes et rien que çà donc oui fondamentalement l'appel à la methode est plus long.

Mais si on y regarde de plus prêt le test benchmark est fait sur un cas simple ou l'on a pris soins de ne faire varier que le parametre methode/function
Autrement dit on ignore l'avantage qu'on tire par la construction d'un code plus construit, puisqu'on s'arrange pour les construire aussi bien l'un que l'autre sans pour autant regarder lequel aurra été le plus facile à construire ,à maintenir et le benchmark ne regarde pas du tout cette aspect de mainteance puisqu'on l'essaye la encore sur des cas simple

Autrement dit le benchmark prouve que fondamentalement plus on rajoute de couche plus on baisse les perf. Notre programme serais donc bien plus performant en Assembleur qu'en PHP
Pourtant quelques hoses me dit qu'en pratique çà n'est pas du tout vrai car notre assembleur deviendrait bordelique a souhait au bout d'1 ou 2 ans de maintenance si déjà on a réussie à programmer la meme chose en assembleur....

Bref donc ce que je pense c'est que la POO permet surtout de se simplifier la vie si on sait comment s'y prendre et que par conséquent çà a des effet bénéfique sur les perf!