Optimisation de scripts PHP/MySQL

Ok j'avais pas vu ca comme ca mais ca peut etre int�ressant :D

Citation:

---

Envoy� par Dozer

On peut ainsi utiliser directement les variables, en plus on utilise un mysql_fetch_row au lieu d'un
mysql_fetch_array

---

Oui mais il n'y a quasiment aucune diff�rence. Le manuel le rapelle bien, la fonction mysql_fetch_array est aussi rapide que mysql_fetch_row (mtsql_fetch_row est un cas particulier de mysql_fetch_array avec result_type � MYSQL_NUM).

Pendant mes longues heures sans internet, j'ai cr�� un bench :)

http://iubito.developpez.com/php/bench.php

Au programme :
- Guillemets et apostrophes dans les cha�nes
- while (list($key,$value) = each($array)) ou foreach ?
- $array['key'] - $array[key]
- str_replace : plusieurs appels ou avec des tableaux ?
- Application 1 : enlever les accents
- file_exists ou is_file ?

et possibilit� de voir la source du bench.php, faites un copier/coller et testez sur votre ordi pour voir si les r�sultats correspondent aux miens. Vous aurez pas forc�ment la m�me vitesse de calcul, mais vous devez normalement arriver aux m�me conclusions que moi ("untel + rapide que l'autre"...)

Perso ma config est un AMD XP2400+ avec 1Go de RAM donc �a trace pas trop mal :)

Youpi! C'est vraiment g�nial ^^
Beaucoup de choses �taient pr�visibles mais ton bench permet de voir dans quelle mesure cela influence sur les performances.
Je me posais aussi des questions sur le foreach ou while et bien la j'ai la r�ponse :D

merci!

Si vous avez d'autres choses � tester dites-le moi, j'ai construit ce bench en relisant mes fonctions de mon projet, pour optimiser le bazar...

Au fait une question. Quand on utilise while avec un mysql_fetch_* :

while( $row = mysql_fetch_array($result_BDD) )

c'est pas la peine de mettre de each? Le mysql_fetch_array s'occupe du pointage?

en fait il faut bien diff�rencier le while et le foreach.
Tu peux faire un foreach sur un tableau ou sur quelque chose dont tu connais la longueur.

L'algo est :

Code:

---

1 2 3

POUR CHAQUE ELEMENT du tableau ...instructions... FIN POUR CHAQUE

---

Le while execute tant qu'une condition est remplie.
while(true) boucle � l'infini puisque true (vrai) est toujours vrai.
Donc un while(mysql_fetch_*), il faut regarder que mysql_fetch_* renvoie quelque chose, ou renvoie null quand il n'a plus rien � renvoyer.
L'algo est :

Code:

---

1 2 3

TANT QUE mysql_fetch_ renvoie quelque chose (!= null) ...instructions... FIN TANT QUE

---

Le fetch renvoie les lignes une � une donc tu ne sais pas au d�but combien il y a de lignes.
Tu peux faire un mysql_numrows pour avoir le nombre de r�sultat, mais un foreach ne marche pas puisque tu connais uniquement le nombre, tu n'a pas r�cup�r� les infos.

voila je fais un peu de pub mais j'ai realis� quelques tests sur certaines fonctions, notamment la lecture de fichier en local et a distance et le parcours de tableaux.
d'autres tests sont en cours de realisation, mais si deja il y en a que cela peut interesser ...
http://www.phplibrairies.com/index.p...1&tutorial=147

Citation:

---

Envoy� par iubito

Citation:

---

Envoy� par _Gabriel_

salut,

- les calculs r�p�t�s dans les boucles du style

Code:

---

for($i=0;$i<sizeof($arr);$i++)

---

ca c'est pas bon!!!

---

peux-tu pr�ciser un peu, je capte pas l�...

---

simplement, � chaque it�ration de la boucle, il doit tester la condition, donc re-calculer � chaque fois la taille du tableau. La suggestion est de ne le calculer qu'une seule fois et stoquer le r�sultat dans une variable. Ainsi on sait � quoi comparer � chaque fois, sans recompter le nombre d'�l�ments par sizeof

Un truck aussi, faut essayer de rapprocher le plus possible le mysql_connect du mysql_close.

Moi par exemple, ca se connecte au debut puis ca se ferme avant d'envoyer du html (dans h_page.php)

Est-ce que la fonction mysql_close() est vraiment utile ?
Ca a un INpact sur la vitesse d'execution ? Sur la s�curit� ?

melmel

De toute fa�on d�s que ta page php est ex�cut�e enti�rement, les connexion sont ferm�es (�quivalent � mysql_close).
:arrow: donc vitesse �a change rien
:arrow: s�curit� je pense pas...
:arrow: par contre une connexion � mysql (c'est une ressource) prend de la place en m�moire. Faire un mysql_close lib�re donc de la m�moire.
A noter que PHP dispose d'un garbage collector.
+ d'infos sur les ressources ici : http://fr.php.net/manual/fr/language.types.resource.php

C'est du m�me ordre que le mysql_free_result apr�s un mysql_query (voir ici).

Pour �crire en plus propre encore le

Code:

---

for($i=0;$i<sizeof($arr);$i++)

---

on peut faire

Code:

---

for($i=0,$j=sizeof($arr); $i<$j; $i++)

---

tout en une ligne ! :) optimis� niveau vitesse

Sinon, ya la mise en cache qui peut etre interresante :
http://www.idfr.net/etude_apache/fr/caching_opcodes.php

Enfin, pour MySQL �a change rien...

Je crois qu'on s'est un peu egarer par rapport a la question pos� de depart
Pour te repondre j'ai mis dans un while un msql_fetch_row($sql) et ca marche tres bien j'ai fait un menu deroulant un tableau plein d'autres encore vraiment ca marche pas de souci

Code:

---

1 2 3 4

while( $row = mysql_fetch_row($sql)) { echo"<tr><td>$row[0]</td></tr>\n<tr><td>$row[1]</td></tr>"; }

---

Ce code fonctionne a merveille si bien sur tu a plusieur champs dans ta base
Pense que le premier champs de ta base est toujours 0
voila n'hesite pas a me contacter pour de futures questions

emrys, il a d�j� �t� dit que mysql_fetch_array n'est pas plus lent que mysql_fetch_row et ajoute un confort d'utilisation.

Aller, un petit coup d'optimisation comme on en a parl� dans ce topic :

Code:

---

1 2 3 4

while( $row = mysql_fetch_row($sql)) { echo"<tr><td>$row[0]</td></tr>\n<tr><td>$row[1]</td></tr>"; }

---

=>

Code:

---

1 2 3 4 5

while( $row = mysql_fetch_row($sql)) { echo '<tr><td>'. $row[0] .'</td></tr> <tr><td>'. $row[1] .'</td></tr>'; }

---

Au quel cas, faire un tableau avec une cellule par ligne, c'est pas terrible, vaut mieux faire des listes <ol> ou <ul>, avec du style ;)

Bonjour,

Voil�, depuis tr�s longtemps je me pose de grosses questions sur l'optimisation du php mais j'ai souvent du mal � trouver des r�ponses.
Alors d�j�, question g�n�rale : comment faire pour tester efficacement un script ou carr�ment l'�x�cution d'une fonction, j'ai bien un script qui calcule le nombre de milisecondes entre le d�but et la fin mais ca donne des chose assez diff�rentes � chaque fois (forc�ment vu l'unit� de temps) : est-ce qu'il faut multiplier l'�x�cution et faire une moyenne, ou y-a-t-il des outils ?

En attendant de savoir faire, est-ce que quelqu'un aurait des r�ponses aux questions suivantes :
1- le fait de faire des fonctions imbriqu�es les unes dans les autres et de les appeler est-il beaucoup plus long que d'ex�cuter le script en bloc tel quel (parce que c'est quand m�me bien pratique pour la lisibilit�) ?
2- lorsqu'on appelle dans une page php un grand nombre de fonctions mais de fa�on variable, vaut-il mieux les mettre toutes dans un seul fichier B, faire l'include une seule fois quite � ne pas servir de la moiti� des fonctions ou vaut-il mieux mettre les fonctions dans des fichiers diff�rents et ne charger chaque fichier que si on en a besoin mais donc faire plus d'includes et m�me beaucoup ?
Bon je crois que c'est tout pour commencer :)
Merci d'avance !

Citation:

---

Envoy� par erzebet

Bonjour,

Voil�, depuis tr�s longtemps je me pose de grosses questions sur l'optimisation du php mais j'ai souvent du mal � trouver des r�ponses.
Alors d�j�, question g�n�rale : comment faire pour tester efficacement un script ou carr�ment l'�x�cution d'une fonction, j'ai bien un script qui calcule le nombre de milisecondes entre le d�but et la fin mais ca donne des chose assez diff�rentes � chaque fois (forc�ment vu l'unit� de temps) : est-ce qu'il faut multiplier l'�x�cution et faire une moyenne, ou y-a-t-il des outils ?

---

Oui, multiplie, par 100, 1000, 10000, 1 million si il faut, y'a toujours des petites variations, mais �a donne une id�e. Si tu as 2 possibilit�s d'impl�mentation d'un algo, �a te permet de comparer.

Citation:

---

En attendant de savoir faire, est-ce que quelqu'un aurait des r�ponses aux questions suivantes :
1- le fait de faire des fonctions imbriqu�es les unes dans les autres et de les appeler est-il beaucoup plus long que d'ex�cuter le script en bloc tel quel (parce que c'est quand m�me bien pratique pour la lisibilit�) ?

---

fonctions = + lisible, + souple (tu modifie un truc �a le modifie pour toutes les utilisations que tu vas faire.
Au niveau m�moire, la fonction va prendre l'espace m�moire n�cessaire juste le moment de son ex�cution, puis le lib�re en sortant.
�a ne fait pas ralentir de cr�er des fonctions.

Citation:

---

2- lorsqu'on appelle dans une page php un grand nombre de fonctions mais de fa�on variable, vaut-il mieux les mettre toutes dans un seul fichier B, faire l'include une seule fois quite � ne pas servir de la moiti� des fonctions ou vaut-il mieux mettre les fonctions dans des fichiers diff�rents et ne charger chaque fichier que si on en a besoin mais donc faire plus d'includes et m�me beaucoup ?

---

Tout d�pend, c plus une question de lisibilit� je pense.
Si tu as une s�rie de fonctions pour faire le caf�, et une autre grosse s�rie pour servir une bi�re fra�che, c + propre de s�parer dans 2 fichiers.
D'un autre c�t�, un seul fichier pour les fonctions c + facile � inclure.
A moins que je me trompe, avoir un include avec beaucoup de fonctions dont pleins qui ne vont pas servir, �a va pas bouffer de la m�moire pour rien.
A confirmer quand m�me, doit y avoir un 'tit chouilla de m�moire utiliser pour "d�clarer" toutes les fonctions, y compris les non-utilis�es, mais �a doit pas �tre �norme.

au niveau de l'appel des fonctions de fa�on g�n�rale, appeler une fonction prend quand m�me un peu de proc, mais rien de comparable aux gains de lisibilit�

(appel d'une fonction =
+ empilement de l'adresse de retour
+ saut au d�but de la fonction
<ex�cution de la fonction>
+ r�cup de l'adresse de retour sur la pile
+ saut � cette adresse
soit 4 instructions en plus : n�gligeable)