Discussion :

[poussinphp]

Suite à une envie d'optimiser mon site au maximum car l'hebergeur est assez lent pour le php je cherche à orienter la version 2 de mon portal php vers l'optimisation au maximum. La refonte complete est un passage obligé et je me pose quelques questions.

1 ) Un script et en générale plus rapide avec des fonction et des class ou avec du procedurale?
2 ) Les commentaires, ça ralenti ?
3 ) mieux vaut une ligne de commande complexe ou 2 lignes simples?

Je sait qu'un post-it existe sur se point mais je trouve qu'il est un peut fouilli (peut être que faire une partie de la FAQ php sur l'optimisation serais une bonne chose, non? )

[genova]

Sérieusement a ce niveau là c'est du chipotage, ton script prendra légèrement plus de mémoire avec des classes et fonctions, mais sera bien plus organisé et lisible.

Pour les commentaires ca ne bouffe rien du tout comme temps puisqu'il sont virés du code "compilé" mis en cache par PHP.

[Amnesiak]

En ce qui concerne l'orienté objet, il est certain qu'une programmation procédurale est, d'un point de vue rapidité d'exécution, plus performante qu'une programmation orientée objet.

Pour les commentaires, je ne pense pas qu'ils soient un frein important puisqu'ils sont tout simplement ignorés par l'interpréteur PHP.

[johan_barbier]

Hello,

ouais, plutôt que de toucher à la clarté de ton code, vérifies plutôt que tu codes "logiquement".
J'entends par là, les trucs à éviter, et facilement évitable, comme "ne pas mettre de fonction dans l'expression d'un for, mais sortir cette fonction et attribuer son résultat à une variable, puis utiliser cette variable dans le for.
Ex:
for ($i = 0; $i < count ($tablo); $i++) // nan

mais

$cpt = count ($tablo);
for ($i = 0; $i < $cpt; $i++) // voui.

C'est basique, c'est juste un exemple parmi tant d'autres. Mais c'est le genre de truc qui peuvent vite bouffer des ressources si on les cumule. Et c'est facile à corriger, comme mauvaise habitude ;-)

Vérifie aussi tes requêtes, si tu en as...ça vient souvent de là, les lenteurs. Une bonne structure avec de bonnes requêtes peuvent diviser le temps bouffé par 100 parfois, voire plus si vraiment tout était à jeter.

[loufoque]

Oui enfin il va bien plus vite d'utiliser foreach.

[johan_barbier]

C'était un exemple...et foreach () n'est pas forcément adapté à ce que fait for ().

[xave]

Je suis d'accord avec poussinphp, ce pourrait être pas mal d'aborder les points d'optimisation de code dans la FAQ... On a un peu de mal à s'y retrouver dans le post-it.

Je suis même prête à donner un coup de main au besoin.

[genova]

Le truc c'est qu'il faut pas confondre chipotage et optimisation.
Sur un script de bourrin avec des boucles dans tous les sens c'est sur qu'il faut optimiser chaque routine, mais sur un script qui est un enchainement d'action la procédure est tout autre (optimisation des requètes surtout par exemple).

Optimisation est un grand mot qui dépend du script en question ...

[xave]

Effectivement, je suis d'accord ça passe d'abord et avant tout par l'organisation du script.

Mais une fois que c'est fait et que les requêtes vers les bases sont nickel, on peut sans doute encore y gagner un peu, encore faut-il savoir comment...
On en devine pas forcément que foreach est plus performant qu'une boucle for pour parcourir un tableau, surtout quand on débute...

[loufoque]

C'était un exemple...et foreach () n'est pas forcément adapté à ce que fait for ().

Pour itérer un tableau, non seulement foreach est plus adapté mais aussi bien plus performant.

[hugo123]

Il me semble que bien souvent ce sont les requêtes qui prennent le plus de temps et qu'une passe importante sur les requêtes (les explain plan sont ils bons ?) permet de gagner en perf. D'ailleurs le recalcul des statistiques régulièrement sur les grosses tables permet d'éviter quelques lenteurs.
Ensuite pour ce qui est du code, j'aurais tendance a croire que ce sont surtout les changements de logique qui permettent d'aller plus vite plutot que le débat sur for ou foreach.

Pour les commentaires, j'avais entendu une fois un truc, franchement j'ai jamais su si c'était vrai et j'aimerais bien une réponse la dessus.
Effectivement les commentaires sont ignorées par le compilateur. Mais pour un compilo C, on compile une fois, on obtient un binaire donc le binaire n'a plus les commentaires et basta.
Mais pour du php, on recompile a chaque fois. Il y a un cache de code ou pas ? Si ce n'est pas le cas, lire un fichier avec 50% de commentaire c'est quand même plus lent, même s'il les ignore non ?
Si j'ai un simple echo et 150 000 lignes de commentaire, mon script sera compilé plus lentement si je ne m'abuse ?
Pas contre une réponse la dessus.

[genova]

Bien entendu que ton fichier sera compilé moins rapidement avec 15 000 lignes de commentaires ... faut prendre en compte aussi la taille du fichier, ton petit fopen() en C va mettre plus de temps à lire un gros fichier qu'un petit fichier.

Par contre il me semble que PHP est mis en cache par défaut, le code PHP est transformé en opcode qui est en gros une sorte de binaire made in PHP, donc sans les commentaires. Cet opcode est ensuite recompilé une seconde fois. Donc en clair les commentaires seront bels et bien ignorés.

[poussinphp]

Pour en revenir aux commentaires, je pense qu'il serais peut être plus judicieux, de garder une version dev avec les commentaires et une version online sans les commentaires, non?

Pour se qui est de la partie optimisation dans la FAQ sa serais génial, car beaucoup ont des idées et des astuces pour optimiser le code.

De plus, je pense que la lenteur de mon site est du aux requetes mysql mais bon, c'est un portal donc la connection à des tables est demandé 3 voir 4 fois à chaque page (menu dynamique par exemple), (positionnement des 'blocs'), (infos utilisateurs)....

[genova]

Non, la connection vers MySQL n'est demandée qu'une seule fois, avec mysql_connect(), au début de ton script.

Lorsque tu effectue une requète avec mysql_query(), la connexion ouverte est utilisée. Le plus long en général dans une page normal c'est justement cette connexion vers mysql, la majorité des requètes sont extrèmement rapides (sauf si tu fais une requète de la mort qui tue avec triple jointure, double distinct et triple saut en hauteur ^^).

[hugo123]

Aucune page n'est "normale" (loi de murphy appliqué au php ^^)

Et si je regarde mon petit forum phpbb et les stats habituelles des pages c'est 5% dans le code PHP et 95% dans les requêtes SQL.

L'optimisation des requêtes est, a mon humble avis, un axe majeur d'optimisation de performances.

[mathieu]

Donc si on résume, les avantages de la programmation procédurale sont :
- développement plus rapide puisque la phase d'analyse est réduite
- exécution plus rapide

Et les avantages de la programmation orienté objet (POO) par rapport à la programmation procédurale :
- facilité d'ajout de nouvelles fonctionnalités
- debugage simplifié

Bien entendu la POO à d'autres avantages que vous trouverez dans l'article suivant :
http://java.developpez.com/livres/penserenjava/

[genova]

Je ne suis sincèrement pas convaincu que la programmation orientée objet influence la rapidité du script, je suis certain qu'un benchmark nous révèlerait que bien entendu la poo est plus lente que la programmation procédurale, mais quand il s'agit de centièmes de seconde c'est vraiment négligeable.

[ska_root]

On parlait bien d'optimisation au départ ?

1. donc je partage l'avis de loufoque concernant la fonction foreach, ya pas de petites économies... je l'utilise le plus souvent possible.
2. je partage aussi l'avis de hugo123 et de genova, 80% (sinon plus) du gain de performances sera réalisé du côté implémentation des données et si l'on respecte un pool de connexion
3. les commentaires, c'est du chipotage, qui met 50000 lignes de commentaires dans une page ?
4. la POO ne sera pas un boulet mais sera un plus si tu développes un projet d'envergure, car une méthodologie facilitera la compréhension, l'evolution, le déboguage, la ré-utilisation. De plus si tu utilises PHP5 tu bénéficies de la gestion des exceptions et de la visibilité des champs et méthodes donc de la rigueur dans ton code. Dis-toi que dans 3 mois, revenir sur un portion de code est beaucoup moins évidente dans du procédural que dans de l'objet, surtout si vous étes plusieurs à développer.

voilà, j'ai mis mon grain de sel ;-)

[EDIT]
J'en profite pour dire qu'avec la venue de mysql5 on pourra aussi énormément économiser (load-balancing) avec les procédures stockées, en attendant rien n'empêche de faire des prepared-statement si on a mysql4.1...

[johan_barbier]

Citation:
C'était un exemple...et foreach () n'est pas forcément adapté à ce que fait for ().

Pour itérer un tableau, non seulement foreach est plus adapté mais aussi bien plus performant.

Lol, j'ai pas dit le contraire. C'était juste un exemple pour montrer que la bonne utilisation des fonctions est aussi indispensable. Je vais dire ça autrement, pour for () : for () évalue l'expression à chaque itération de boucle, donc, il ne faut pas mettre de fonction dans cette expression (si possible).

Pour mon avis sur le reste, je suis d'accord avec la plupart :
- la poo doit surtout être vu côté praticité, évolution, réutilisation du code. Mais d'après ce que je sais, c'est plus lent que la prog procédurale. A moins d'être très très fort en poo, je suppose.
- et oui, c'est bien plus fréquemment les requêtes (et donc la structure de la base) qui ralentissent un site. Donc quand on utilise une base, la 1ère chose dont on doit s'inquiéter, c'est de sa structure. Une base bien structurée, bien réfléchie, donne généralement des requêtes faciles...et des requêtes faciles sont généralement des requêtes rapides (à moins de coder les requêtes comme un bourrin, mais bon...).

Quant à la faq, ça me semble aussi une très bonne idée.
Un petit article valable surtout si on a la main sur le serveur hébergeur :
http://phplens.com/lens/php-book/optimizing-debugging-php.php

[loufoque]

Lol, j'ai pas dit le contraire.

Ton exemple avec for réalisait l'itération d'un tableau....