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