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à !