Optimisation de scripts PHP/MySQL [D�bat]

**sigap** · 06/08/2006, 23h23

parce le processeur PHP �value les instructions "echo", il est pr�f�rable d'utiliser echo 'hello world' au lieu d'utiliser echo "hello world". Avec les guillements PHP parcoure toute la chaine afin d'y chercher d'�ventuelles variables. Si vous n'en proposez pas ? alors utilisez les quotes.

**Yogui** · 06/08/2006, 23h29

Salut

Nous avons un tutoriel � ce sujet : http://pbnaigeon.developpez.com/tuto...phe-guillemet/

**Blustuff** · 07/08/2006, 02h43

Ce tutoriel est parfait pour induire tout le monde en erreur :

La lisibilit� vaut dans les deux sens. Certes, il est tr�s pertinent que dire que d'afficher de l'html est bien plus ais� avec des guillemets simples du fait de l'usage des guillemets doubles pour les attributs, mais il existe des cas o� les guillemets doubles sont plus pratiques, notement pour les requ�tes mysql. Ce d�tail est scrupuleusement omis.
L'auteur est-il conscient qu'il parle dans tout un paragraphe d'une optimisation de l'ordre d'une � cinq microsecondes, tout en sachant qu'un script moyen a un temps d'execution de l'ordre de 100 ms ? (0.01 % d'optimisation par chaine)

**Yogui** · 07/08/2006, 05h34

Il me semble que tu n'as pas bien lu le tutoriel. En effet, il traite ces deux points que tu mets en valeur : la section IV Conclusion �voque et illustre un cas d'utilisation de cha�ne contenant des apostrophes (il s'agit de SQL, justement), donc un cas d'utilisation o� les guillemets sont bien plus int�ressants pour d�limiter la cha�ne.

Concernant ton commentaire sur l'optimisation ridicule, oui, l'auteur en est conscient et l'a pr�cis� dans le tutoriel. Lis attentivement.

� l'avenir, merci de ne pas poster de remarques cinglantes � 2h43 du matin car cela semble affecter ton jugement.

**Blustuff** · 07/08/2006, 14h22

Non, je maintiens ce que j'ai dit, � 14h18 de l'apr�s midi o� tout le monde est r�veill� car, en pr�cisant les points que j'avance :

La lisibilit� du code avec les guillemets double doit �tre abord� dans le paragraphe o� on parle de la lisibilit� qui s'appelle "II. Lisibilit� du Code"
L'auteur parle de, je cite, "Une diff�rence significative du simple � plus du quadruple !!!" ou encore "cela peut changer beaucoup de choses dans la dur�e d'affichage de la page ou dans le temps d'ex�cution du script.". Quand on est sur un sujet qui parle d'optimisation, il est important de ne pas dire de telles choses. Le temps aurait pu �tre 100 fois plus long, �a n'aurait rien chang� tant que �a concernait des microsecondes. C'est l'exemple parfait de ce qu'il ne faut pas faire en optimisation. (Remarque valable aussi pour les optimisations de code en assembleur)

Cela dit, l'article n'est absolument pas inutile, mais il doit �tre r�vis�.

**Yogui** · 07/08/2006, 15h01

Hmmm...

Un gain de performances n'est-il pas une optimisation ? Il s'agit peut-�tre de microsecondes, c'est un gain. Il s'agit ici d'optimisation, nous sommes donc parfaitement dans le sujet.

Pour rappel, une optimisation ne prend de valeur que dans le cadre d'un site � forte fr�quentation (lourde charge serveur).

La formulation est peut-�tre parfois exag�r�e, mais c'est pour faire prendre conscience au lecteur de l'importance de ce choix (apostrophes ou guillemets). Comme il est dit dans l'article, il faut savoir faire preuve de discernement.

Si tu souhaites encore disserter sur des d�tails de formulation, merci de contacter directement l'auteur de l'article. Ce sujet d'optimisation n'est le bon endroit pour en d�battre.

**Blustuff** · 07/08/2006, 17h26

C'est un bon endroit pour en d�battre. Savoir optimiser un script n'est pas une chose �vidente. Sur un script de plusieurs dizaines de milliers de lignes, on peut analyser ligne par ligne s'il existe une fa�on plus efficace de faire. (Et y passer tout une ann�e) Ce n'est pas la bonne mani�re de proc�der. Il convient lorsque l'on parle d'optimisation de savoir identifier les goulots d'�tranglement, ce qui revient au m�me que de savoir lorsqu'il est int�ressant de chercher � optimiser une portion de code ou non. Le sujet parle d'optimisation, on est exactement dans le sujet. Tu l'avais dit plus avant, je pense que tu n'as pas chang� d'avis, il vaut parfois mieux chercher � rendre le code lisible que le rendre rapide. C'est un bon exemple, et on peut en tirer plein de bonnes conclusions.

**Yogui** · 07/08/2006, 17h32

En effet et je vais plus loin : je pense qu'il est toujours pr�f�rable de bien organiser son code plut�t que de le rendre ultra efficace. � la longue, le code bien �crit sera tr�s facile � maintenir tandis que du code mal �crit ne fonctionnera plus lorsque quelqu'un y mettra son nez (ou bien cette personne perdra de longues heures � �tudier sa structure).

L'optimisation, comme la s�curit�, est toujours un compris entre ergonomie et efficacit�.
Pour r�ellement optimiser un script, il faudrait n'utiliser aucun wrapper (uniquement les fonctions fournies en standard avec PHP), ce qui augmente consid�rablement le temps de d�veloppement.

L'optimisation d'un script passe par l'optimisation du temps de d�veloppement, l'optimisation de la patience des d�veloppeurs, etc.

**berceker united** · 13/09/2006, 14h04

Question :
Y a t'il une diff�rence entre

mysql_free_result($rs)
et $rs = null ?

Un me certifie que ceci revient au m�me et moi je pense que non. Concretement nous ne savons ce qu'il se passe dans le free_result.

**Yogui** · 13/09/2006, 15h41

Concr�tement, cela n'a pas une grande utilit� � part lib�rer quelques minimes ressources avant que PHP le fasse de lui-m�me en terminant le script, ce qui surviendra quelques milli�mes de secondes apr�s ton mysql_free_result(). Cela dit, si tu utilises des connexions persistantes, le comportement change probablement.

Pour te r�pondre, il est toujours pr�f�rable d'utiliser les fonctions sp�cifiques plut�t que les m�thodes g�n�ralistes. En effet, cette fonction peut tr�s bien lib�rer davantage que la simple variable (certainement quelque chose c�t� MySQL, etc.), alors que l'�craser se limiterait � lib�rer la m�moire associ�e.

**berceker united** · 13/09/2006, 16h14

C'est ce que je me disait aussi. En tous cas je m'oblige � le mettre ainsi que l'utilisation de unset() car lorsqu'il y a que 2-3 p�lerins sur gain est trop infime pour que le serveur le remarque mais lorqu'il y toute la populasse qui tombe, l�, la qualit� du code et l'optimisation peut prendre toute son importance. Pour ce cas pr�cis effectivement cela va se faire t�t ou moyennement tard.
Merci.

**jpascal** · 14/09/2006, 17h14

Bonjour,

Vaut-il mieux utiliser

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
if ( isset($_POST['cat']) || isset($_GET['cat']) )
{
	$cat = ( isset($_POST['cat']) ) ? $_POST['cat'] : $_GET['cat'];
}
else
{
	$cat = 'lieux';
}

ou

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
if ( isset($_POST['cat']) )
{
	$cat = $_POST['cat'];
}
else if ( isset($_GET['cat']) )
{
	$cat = $_GET['cat'];
}
else
{
	$cat = 'toto';
}

?

**berceker united** · 14/09/2006, 17h21

Envoy� par jpascal

Bonjour,

Vaut-il mieux utiliser

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
if ( isset($_POST['cat']) || isset($_GET['cat']) )
{
	$cat = ( isset($_POST['cat']) ) ? $_POST['cat'] : $_GET['cat'];
}
else
{
	$cat = 'lieux';
}

ou

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
if ( isset($_POST['cat']) )
{
	$cat = $_POST['cat'];
}
else if ( isset($_GET['cat']) )
{
	$cat = $_GET['cat'];
}
else
{
	$cat = 'toto';
}

?

Je pense qu'en terme d'optimisation �a ne changera pas grand chose par contre en claret� oui.
J'aurais plutot fait ceci.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
$cat = '';
if($_SERVER['REMONTE_METHODE']=='POST'){
   if(isset($_POST['cat'])) $cat = $_POST['cat'];
}elseif($_SERVER['REMONTE_METHODE']=='GET'){
   if(isset($_GET['cat'])) $cat = $_GET['cat'];
}

Alors pour ceci ? L� tu nous a montr� avec une variable mais imagine qu'il y en a 10. L�, �a risque de devenir assez freestyle.

**Yogui** · 14/09/2006, 18h03

La notation espac�e ne me d�range pas le moins du monde, contrairement � celle propos�e par beckerunited qui a ses inconv�nients.
@jpascal : En fait, tes deux propositions n'ont pas le m�me comportement. Il ne s'agit pas d'optimisation mais de pure logique. Fais des tests si tu ne vois pas ce que je veux dire mais prends garde � ces conditions, elles ne signifient pas la m�me chose.

**berceker united** · 14/09/2006, 18h55

Envoy� par Yogui

La notation espac�e ne me d�range pas le moins du monde, contrairement � celle propos�e par beckerunited qui a ses inconv�nients.
@jpascal : En fait, tes deux propositions n'ont pas le m�me comportement. Il ne s'agit pas d'optimisation mais de pure logique. Fais des tests si tu ne vois pas ce que je veux dire mais prends garde � ces conditions, elles ne signifient pas la m�me chose.

Personnellement, je ne comprend pas. Dans tous le cas il test si cat est d�finit en post ou en get. de la il r�cup�re l'info dans le cas contraire il y en a une par defaut.

**Yogui** · 14/09/2006, 19h42

J'ai compris... Ouaip, d�sol�, j'avais lu un peu rapidement.
La 2� solution est meilleure simplement car elle �vite de r�p�ter les traitements. C'est plus optimis�, certes, mais surtout c'est mieux organis�, mieux structur� et plus facile � maintenir (surtout l'op�rateur ternaire, � �viter).

**berceker united** · 14/09/2006, 19h52

Envoy� par Yogui

J'ai compris... Ouaip, d�sol�, j'avais lu un peu rapidement.
La 2� solution est meilleure simplement car elle �vite de r�p�ter les traitements. C'est plus optimis�, certes, mais surtout c'est mieux organis�, mieux structur� et plus facile � maintenir (surtout l'op�rateur ternaire, � �viter).

Ok,
Concernant ma m�thode ou y aurait il un inconv�niant?

**Yogui** · 14/09/2006, 20h11

D'une part, les accolades ne sont pas align�es, cela ralentit donc l�g�rement la lecture du code. Je d�teste devoir chercher l'accolade ouvrante :/
D'autre part, si la ligne contient de nombreux tests, tu seras oblig� de la mettre sur plusieurs lignes, ce qui suppose une indentation, et l� �a devient n'importe quoi : autant mettre l'accolade � la ligne, c'est plus clair.

Nous avons un tuto en pr�paration � ce sujet.

**viviboss** · 19/09/2006, 13h08

La pr�sentation du code est effectivement tr�s importante : je me bat tout les jurs � mon boulot, parce que pour les autres membres de mon staff, seul importe le r�sultat.

Mais c'est faux : la mise en forme et l'intelligibilit� du code garantissent la p�r�nit� du code, et sa r�utilisation : quand on a 1000 lignes de codes sans commentaires, sans indentations, et avec des variables sans queue ni tete, perso je reprend le tout.

Quand on d�veloppe, et ce dans n'importe quel langage, il faut penser au futur et au recyclage du code !!!!

**berceker united** · 19/09/2006, 13h21

Envoy� par Yogui

D'une part, les accolades ne sont pas align�es, cela ralentit donc l�g�rement la lecture du code. Je d�teste devoir chercher l'accolade ouvrante :/
D'autre part, si la ligne contient de nombreux tests, tu seras oblig� de la mettre sur plusieurs lignes, ce qui suppose une indentation, et l� �a devient n'importe quoi : autant mettre l'accolade � la ligne, c'est plus clair.

Nous avons un tuto en pr�paration � ce sujet.

Concernant les accolades si c'est sur :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part