Discussion :

[iubito]

ah �a y est j'ai capt�, tu voulais dire de ne pas mettre le sizeof($arr) dans l'instruction for... donc �a aurait �t� bien que tu dise ce qu'il faille mettre. Il a fallu te cuisiner un peu pour que tu le sortes.

Et le ob_xxx n'avait rien � voir l�-dedans. Et bon de mani�re g�n�rale �a ralenti le script. Ce que �a peut am�liorer c'est la compression des pages quand le navigateur l'accepte, donc la quantit� de donn�es transf�r�es, mais la vitesse du script sur le serveur non, certainement pas.

[iubito]

un conseil pour clarifier les message, au lieu de mettre des - en d�but, on peut mettre des puces.

Code :

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

1
2
3
4
[list]
[*] première ligne
[*] deuxième ligne
[/list]

ce qui donne

• premi�re ligne
• deuxi�me ligne

[_Gabriel_]

mais la vitesse du script sur le serveur non, certainement pas.

j'ai pas forcement dit que c'etait une v�rit� flagrante et visiblement je suis pas le seul � l'avoir observ�.
++

[iubito]

OK.

Dans la m�me optique que le sizeof...

Code :

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

for ($i=$debut; $i<=$fin-1; $i++) {}

est � remplacer par

Code :

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

for ($i=$debut; $i<$fin; $i++) {}

on �vite la soustraction dans le test, et on remplace <= par <.

[iubito]

et pour des echo multiples, pr�f�rer :

Code :

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

1
2
3
4
echo '<table>'
    .'  <tr>'
    .'     <td>'
    .'une concaténation de chaînes...';

� des echo multiples

Code :

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

1
2
3
4
5
6
 
echo '<table>';
echo '  <tr>';
echo '    <td>';
echo 'un echo pour chaque ligne c'est pas le top!';
...

ou alors dans ce cas-l� ne pas mettre dans les balises php

Code :

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

1
2
3
?><table>
  <tr>
    <td>Dans ce cas, ça sera transformé en un seul echo multiligne...<?php

[_Gabriel_]

salut,

et marche aussi et evite les concatenations

Code :

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

echo '<table>' ,'  <tr>' ,' <td>' ,$var,'une concaténation de chaînes...';

++

[iubito]

salut,

et marche aussi et evite les concatenations

Code :

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

echo '<table>' ,'  <tr>' ,' <td>' ,$var,'une concaténation de chaînes...';

++

Si on �crit en ligne y'a plus aucun int�r�t � faire des concat�nation, autant faire directement echo '<table><tr>...';

Parfois on pr�sente sur plusieurs lignes pour s'y retrouver dans le code PHP.

[Dozer]

Toujours avec MySQL ( de toutes facons, les vraies optimisations ( celles qui font gagner plus que quelques dixi�mes de miscroseconde ) ne touchent principalement que les acc�s BDD).

Il arrive fr�quement lors d'un SELECT, notemment lorsqu'un sp�cifie un WHERE ou �quivalent dans la requ�te, que l'on sache a 100% que le retour de la requete ne comportera qu'un seul enregistrement.

D�ja, la premi�re bonne id�e c'est de ne pas faire de boucle, on peut y aller directement comme ceci :

Code :

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

$results = mysql_fetch_array(mysql_query("SELECT * FROM table WHERE champ = 'valeur'"));

Ensuite, si l'on est toujours dans la meme configuration et que en plus, on nomme les champs que l'on va selectionner dans la requete, au lieu de faire comme ci dessus et d'ensuite utiliser le tableau '$results', on peut utiliser une fonction assez m�conue : list(), comme ceci:

Code :

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

list($var1, $var2, $varn) = mysql_fetch_row(mysql_query("SELECT champ1, champ2, champn FROM table WHERE champx = 'valeur'"));

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

Les malins auront compris que dans le cas ou les retours de requetes sont multiples, on peut utiliser list() sur le tableau analys� par la boucle pour des raisons pratiques.

[matN59]

salut

Il arrive fr�quement lors d'un SELECT, notemment lorsqu'un sp�cifie un WHERE ou �quivalent dans la requ�te, que l'on sache a 100% que le retour de la requete ne comportera qu'un seul enregistrement.

la je suis pas tout a fait d'accord avec toi; je pense qu'il faut -meme si tu t'attends theoriquement a n'avoir qu'un seul enregistrement - a tester le nombre d'enregistrements que tu as recuper�: on ne sait jamais, si un petit malin voulait faire du SQL injection...

[iubito]

je suis d'accord, il faut v�rifier...

[Dozer]

Je suis un peu mort de rire, il m'arrive tr�s souvent que je sache tr�s bien que je vais n'avoir qu'un seul retour, j'en suis sur a 100% et nimporte quel petit malin ne pourrait rien y faire.

Exemple pour les sceptique :

Dans une table avec un champ 'id' d�clar� en auto_increment et clef primaire (cad 99% de mes tables) .

Code :

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

mysql_query("SELECT champ1, champ2, champn FROM table WHERE id = '2'");

Bah je t'assure que je n'aurai qu'un seul retour.

Mais vous pouvez toujours ne pas me croire et tester le nombre de retour ou faire une boucle.

Edit : c'�tait un exemple

[matN59]

on est bien d'accord dans ce cas la
par contre, point de vue optimisation, ta requete est pas terrible...

Code :

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

1
2
 
SELECT *

[Tuxxy]

En parlant des SELECT *, si on a qu'un ou deux champs de l'enregistrement � r�cup�rer, il vaut mieux les sp�cifier :

Code :

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

SELECT nom, email FROM...

Mais si on a r�eellement besoin de tous les champs, c'est quoi le plus rapide?

Et puis quand un select renvoie plusieurs enregistrement, vous fa�tes comment pour y acc�der les uns la suite des autres?

Code :

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

1
2
while(list($var1)=mysql_fetch_row($result))
...

ou avec each?

Je pense que la dessus on doit pouvoir gagner plein de temps sur des requetes avec plein d'enregistrements.

[Nonothehobbit]

Une tr�s bonne optimisation niveau quantit� de donn�e est l'utilisation des m�thodes __sleep() et __wakeup() quand on veut sauvegarder un objet serialis� (je connais pas le mot en fran�ais).

Si par exemple j'ai un objet voiture, ily a des caract�ristiques qui ne changent pas la marque, la puissance, le nombre de pneus... Dans la fonction __sleep() je pr�cise que je ne souhaite garder que les attributs variables (kilom�trage, jauge d'huile, d'essence,...) ainsi que le type de voiture. Et ensuite dans la fonction __wakeup(), je vais charger � partir de la base de donn�e les informations fixe (marque, puissance,....) qui correspondent au type de voiture.

Ainsi, l'objet serializ� prend bcp moins de place.

[iubito]

j'ai pas tout compris l� ton sleep et wakeup mais si c'est pour faire des requ�tes � la base pour retrouver des infos... ouais... :-/

[Nonothehobbit]

C'est pour le cas o� on voudrais sauvegarder un objet php tel quel, dans une session, un fichier ou une base de donn�e. Pour ce faire on est oblig� de transformer l'objet en cha�ne de caract�re via la fonction serialize (la fonction est automatiquement appel�e quand on sauvegarde dans une session).

Cette cha�ne de caract�re contiendra toutes les donn�es de l'objet (mais pas les m�thodes), le probl�me est que pour un gros objet �a prend de la place, d'o� l'int�r�t des m�thodes __sleep() (pour all�ger l'objet) et __wakeup() (pour r�cup�rer les informations non enregistr�e).

D�sol� si j'ai pas �t� tr�s clair. Je vous fais par de cette optimisation car elle m'a �t� tr�s utile r�cemment pour diminuer le poids d'objets que je souhaitais sauvegarder en base de donn�es.

[iubito]

ah ok y� comprend mieux
m�me si les objets et les sessions en php c'est pas mon point fort

[Tuxxy]

ben d'un cot� tes objets s�rialis�s prennent moins de place mais de l'autre, tu es oblig� de refaire des requetes pour compl�ter les infos fixes que tu as retir� lors de la s�rialisation.
Les requetes SQL entra�nent un ralentissement.
Donc entre place occup�e et performances, il faut choisir.

[Nonothehobbit]

Pour ma part je charge toutes les donn�es "fixes" (dans cet exemple ce serait toutes les donn�es sur les type de voitures) lors du login et je les garde en session. Ainsi quand j'ai besoin de charger un objet "voiture", je n'ai que les donn�es variables � charger � partir de la bdd le reste je le charge � partir des donn�es gard�es en session.
Plus besoin de faire une grosse requ�te pour r�cup�rer toutes les donn�es invariables. C'est donc � la fois optimis� en temps (un seul chargement) et en poids (l'objet voiture est bcp moins lourd).

Le seul inconv�nient est que ce n'est pas forc�ment adapt� � ts les probl�mes. Etant donn�e que mon objet voiture est s�rialis�, je ne pourrais jamais faire de requ�te pour en extraire des donn�es ou faire des stats. Mais �a peut servir dans certain cas.

A noter que dans cet exemple, il est pr�f�rable d'enregistrer les donn�es dans la base de donn�es "champs par champs" (cad un champs pour chaque attributs) et non un seul champ contenant l'objet s�rialis�. Mais par contre �a peut s'av�rer tr�s pratique d�s qu'on doit manipuler des objets contenant des listes d'autre objets.
Ca �vite de cr�er un table interm�diaire contenant les liens entre les objets, ce qui peut pas mal ralentir le script quand il y a beaucoup d'objet avec de grandes listes.

Imaginon un objet 'personne' poss�dant une liste d'objet 'meubles'.
5 000 personnes sont stock�es, chacune poss�dant dizaine de meubles en moyenne. Et bien dans la table de lien �a fera 50 000 liens personne<->meuble et les requ�te de s�lection pour trouver quels meubles appartiennent � quels personnes seront d'autant plus longues.

Par contre si on utilise des objet serialis�s et bien il suffit de rajouter un champ 'liste_meubles' dans la table personne, contenant la liste des meubles sous forme d'objet s�rialis� (une champ texte suffit). Et l�, plus besoin de faire de jointure sur une table gigantesque. Cependant on ne pourra plus faire de statistique directement par une requ�te ou encore faire la requ�te inverse, cad r�cup�rer la liste des personnes poss�dant un meuble donn�.

C'est comme toute structure de donn�es, �a a ses avantages et ses inconv�nient, il faut voir en fonction de ses besoins...

[iubito]

int�ressant ce que tu dis l� !