Discussion :

[johan_barbier]

Oui, ça restait un exemple, donc...
Bon, lol, ça me fatigue.
Ok, mon exemple était mauvais.
Néanmoins, ce que j'y dis reste vrai.
Reste à lire ce que j'y dis, au fond...

[xave]

Enfin, si on essayait de recentrer un peu le sujet...

Il était question d'ajouter un chapitre "optimisation des scripts" dans la FAQ php...
Il me semble que devraient y figurer tous les trucs et astuces pour optimiser ses scripts du plus évident au plus astucieux, on pourrait définir par exemple un ordre de priorité en plaçant les évidences comme l'optimisation des requêtes en début de liste...

[genova]

L'optimisationh des requètes est tellement aléatoire, de plus il existe déjà un artticle de sqlpro je crois qui donne quelques astuces sur les requètes (par exemple faire un COUNT(*) au lieu d'un COUNT(champ)) et qui compare diverses trucs dans la structure de simples requètes.

Un truc sympa aussi serait de donner des optimisations sur la mémoire, par exemple ne pas passer de gros tableaux en argument mais utiliser les références (ou la globalisation suivant le cas).

[johan_barbier]

Faut faire une pétition ? ;-)
Moi je signe pour, en tous cas. Je trouve que c'est une excellente idée.
On peut aussi ne pas oublier de prendre en compte l'optimisation html/css, dans le lot.

[xave]

Pour +1

[hugo123]

L'optimisation HTML serait a mon avis plus indiqué dans la partie HTML du forum, a la limite avec un lien de la FAQ PHP vers la FAQ HTML.

De même, même si l'optimisation de requête est un axe majeur d'amélioration des performances, ceci devrait rester dans les FAQ des BDD concernés. En effet certains axes d'optimisation sur un SGBD ne sont peut être pas identique sur une autre. Mettre dans une FAQ php des astuces concernant Mysql risquerait de déstabiliser les utilisateurs de php avec oracle, postgress etc...

Pour moi, une FAQ Php devrait concerner uniquement la programmation en php. Par contre des liens vers des bons tutoriaux existants pour html, bdd etc... pourrait être appréciable.

[johan_barbier]

Oui, je suis entièrement d'accord avec ce principe.

[sekaijin]

concernant php les optimisation sur un script c'est un peut de la foutaise
à moins de faire un travail sallasse
car si un script doit exécuter 5 000 000 de lignes de code c'est qu'il y a un blème.

les scripts php sont relativement court (comparé à une appli en C ou C++)

il ne reste que peut de temp en memoire. donc les optimisation de pacotille ne peuvent au moieux que faire gagner que quelque millier de cycle d'orloge. à 2,5 GHz c'est peanuts

par contre tout ce qui entoure le code est à surveiller.
la connexion à la base de donnée,
l'optimisation des requête mais sur tout l'indexation approprié et la structure de la base imfluent grandement sur une durée de requête.

il ne ser pas à grand chose d'écrire une requête SQL avec de Joinou des where pour savoir qui va plus vite car en fait cela dépends du moment ou on le fait. c'est la structure de la base, les index et les stastistiquees d'usage de la base qui permettent au moteur SQL de choisir la stratégie à accomplir.

un index sur une table de référence contenant de 1 à 10 entrée n'a pas à être indexée les moteurs SQL considère que sur une telle taille le parcours de l'index est plus couteux que les parcours de la table.

bref je pense qu'une section optimisation de base est à ouvrir dans le forum adéquat.

il n'y a pas que la base qui soit consommatrice de temps.
un mail est très rapide sur le serveur local si celui-ci est correctement configuré

une connexion SMTP improprement configuré est couteux.
LDAP est réputé ultra rapide faut il encore que le réseau le soit.

bref c'est souvant hor de php que les resource temporelle son mangées.

à par ça pour optimiser le code il suffit d'un peut de bon sans

appeler une fonction dans le test d'une boucle implique un calcul à chaque passage
est-ce toujours necessaire ?
parcourir plusieurs fois des collections est-il indispenssable.

le parcours dépendant de deux collection.
un tableau que l'on parcours et pour lequel on va chercher dans un autre.
choisir le bon tableau maitre

bref un code simplement structuré et tu es quasi sur d'avoir des perf quasi optimales

pour ce qui est des commentaire
l'analyseur syntaxique les capture et les passe à l'analyseur gramatical qui les mets à la poubelle.

le code html hors des balises <?php ?> ne passe pas par l'analyseur gramatical il est directement mis dans le buffer. seule son adresse memoire est mis dans un registre.

mais faire un echo d'un code HTML satique n'est pas significativement plus couteux.

A+JYT