Discussion :

[TheRedLed]

Question : est-il préjudiciable de faire trop d'appels de fonctions en php ?
J'ai tendance à le faire pour mieux maintenir le code et rendre la prog plus facile, mais est-ce que ça rallentit sensiblement l'éxecution ?

genre j'ai carrément fait une fonction du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
function Requete($reqSend, $msgerr="") {
$req = mysql_query($reqSend);
$lg = mysql_query($req) or die ("Erreur SQL : ".$reqSend." / ".$mysql_error()." / ".$msgerr);
return $lg;
}

Mais j'espère que ça rallenti pas trop les requetes... Zen pensez quoi ?

edit : et même question sur la POO !

[TheRedLed]

absolument personne ?

[berceker united]

Si tu estimes qu'il y a besoin d'avoir une fonction fait le. Il es préférable d'avoir des fonctions plutôt que du code répété. Même si la fonction est utilisé qu'une fois ça permet d'y voir plus claire pour une relecture ou debuggage.
Je ne pense pas que cela relenti de façon signifactive.

[kankrelune]

Il est inutile de faire des fonction pour simplement utiliser des fonctions natives ça allourdis et le code et le traitement...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
function requete($sql)
{
     $result = mysql_query($sql) or die ('Erreur SQL ['.$sql.'] : '.$mysql_error());
     return $result;
}

mieux vaut prendre la peine de coder le or die directement dans le code... .. .

Sinon Blustuff je trouve tes remarques peu pertinentes et ce pour plusieurs raisons... tout d'abord personnellement (et je suis un des rare) j'utilise les simples quotes MEME dans mes requetes sql... ensuite il n'y a pas de petites optimisation tout est bon à prendre quand on optimise (à partir du moment ou ça ne gène pas dans la lisibilité du code) même quelques centièmes de seconde... quelques centièmes de seconde par ci + quelques centièmes de seconde par là +... ça peut faire un voir plusieurs dixième(s) de seconde... et quand bien même le gain est quasi nul cela permet de prendre certaines bonne habitudes ce qui ne peut être que bénéfique... ta remarque est donc, à mon avis hors sujet... par contre tu le fais remarquer à juste titre optimiser php ne veux pas dire juste optimiser le code mais aussi la configuration de php et le serveur qu'il l'éxécute... .. .

Pour finir je dirais qu'il ne faut pas utiliser de bench fait main à l'intérieur du code c'est trop peu fiable mieux vaut utiliser une extension comme xDebug... .. .

sinon à rajouter au tableau des erreurs courantes en terme d'optimisation

- utiliser strpos à la place de ereg si on utilise pas d'expression régulière
- utiliser les accolades à la place de substr pour récupérer un charactère fixe

@ tchaOo°

[Death83]

Moi j'utilise une fonction pour mes requettes, car je compte le nombre de requettes par page (pour les optimisation justement).

C'est paradoxal, j'allourdie mon code pour l'optimiser lol.

[kankrelune]

Moi j'utilise une fonction pour mes requettes, car je compte le nombre de requettes par page (pour les optimisation justement).

C'est paradoxal, j'allourdie mon code pour l'optimiser lol.

Je fais pareil à la différence pret que j'utilise une class d'abstraction SGDB... donc la il y a un interet à ne pas utiliser les fonctions natives... dans laquelle si le mode de traçage est activé un logger est instancié... mais si le site est en prod le logger n'est pas instancié résultat ça alourdit le code de deux if (un avant la requète et un après) donc autant dire que ça l'allourdie de quasiment rien quand le site est en prod... .. .

@ tchaOo°

[Invité(e)]

apprenez aussi à dénormaliser votre base de données pour éviter les jointures multiples dans vos select.

[Yogui]

Oui, enfin, faites attention avec la dénormalisation, ça peut améliorer la vitesse de traitement mais cela n'optimise ni l'espace disque (au contraire) ni la quantité de traitements (il faut souvent utiliser une sorte de mise en cache).
Bref, attention à la dénormalisation : la normalisation n'est pas là pour faire un joli mot de vocabulaire.

[Invité(e)]

Oui, enfin, faites attention avec la dénormalisation, ça peut améliorer la vitesse de traitement mais cela n'optimise ni l'espace disque (au contraire) ni la quantité de traitements (il faut souvent utiliser une sorte de mise en cache).
Bref, attention à la dénormalisation : la normalisation n'est pas là pour faire un joli mot de vocabulaire.

Oui en effet , c'est vrai on ne fait pas n'imporque quoi comme dans tout.

Mais dénormaliser est souvent indipansable pour les sites à fortes consultations.

Les jointures sous mysql sont pénalisantes comme toute base de données du reste . FAITES LE TEST VOUS MEME !!

injectez 500 000 lignes dans une seule table et faites une requête avec et sans jointure STUPEFIANT.

Ma méthode est la suivante :

en imaginant que vous souhaitiez mette en place un site immobilier ( de consultations de petites annonces ) comme c'est le cas por moi en région paca.

une personne souhaitant vendre son bien glisse une petite annonce dans le site .

cette petite annonce , vous en conviendrez peut faire appel à plusieurs tables

de référence , PAYS , VILLE , REGION , TYPE DE BIEN ETC ...... qui lors de sa consultation fera appel à ces mêmes tables pour reconstituer celle-ci.

eh bien moi je cree une table de consultation qui contiendra toutes les données dont la requête aura besoin pour s'exécuter donc je n'ai qu'une seule table , c'est vrai que cela oblige a refaire une insertion dans cette table
insert select (.....) mais de toutes les facons il faut valider à la main cette petite annonce ,c'est à ce moment précis que je dénormalise donc aucune incidence sur le modéle de données.

[Yogui]

Sans être expert dans ce domaine (faute d'occasion), il me semble que tu peux utiliser des procédures stockées, des vues et d'autres mécanismes automatisés. Me trompé-je ?
Je ferai un bench dès que possible...

[Invité(e)]

Sans être expert dans ce domaine (faute d'occasion), il me semble que tu peux utiliser des procédures stockées, des vues et d'autres mécanismes automatisés. Me trompé-je ?
Je ferai un bench dès que possible...

C'est vrai j'utilise pas mal les procédures stockées sous ORACLE et MYSQL
pour un intranet .Mais vois-tu en hébergement mutualisé c'est souvent impossible , les hébergeurs se refusent à activer ces services , sous prétexte que cela pénalise les serveurs , en dédié je dis pas le contraire.

Dans le cas présent ce serait plutot un trigger qu'il faudrait utiliser;

[berceker united]

C'est vrai j'utilise pas mal les procédures stockées sous ORACLE et MYSQL
pour un intranet .Mais vois-tu en hébergement mutualisé c'est souvent impossible , les hébergeurs se refusent à activer ces services , sous prétexte que cela pénalise les serveurs , en dédié je dis pas le contraire.

Dans le cas présent ce serait plutot un trigger qu'il faudrait utiliser;

Je savais pas que les hebergeurs jouaient les pinces avec les procédures stockées et autre. Je pense que ça pénalise plus le serveur de faire la même chose en code que le serveur de base de données.

[Yogui]

Ce n'est pas qu'ils désactivent ces fonctionnalités mais plutôt qu'ils utilisent un serveur MySQL bien trop ancien (3.23) qui ne les supporte pas. Il faudrait passer à au moins 4.2 pour que cela devienne intéressant ; au mieux, il faudrait une version 5.x...

[Invité(e)]

Ce n'est pas qu'ils désactivent ces fonctionnalités mais plutôt qu'ils utilisent un serveur MySQL bien trop ancien (3.23) qui ne les supporte pas. Il faudrait passer à au moins 4.2 pour que cela devienne intéressant ; au mieux, il faudrait une version 5.x...

non non , les versions de mysql que détiennent les hébergeurs ont la possibilité d'être installées en désactivant ces services.

d'ailleurs chez infomaniak comme chez nexxen ces fonctionnalités sont inactivées

version INFOMANIAK : Distrib 5.0.22

[dorian53]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT pseudo FROM membres LIMIT 40,20

Solution optimisée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT pseudo FROM membres WHERE id_membre BETWEEN 40 AND 60

OK, mais "le problème" est que le site vit et que certains membres (ou topic pour un autre exemple) seront supprimés.
Il est donc impossible d'assurer que l'on obtiendra 20 résultats.

Ma question est, doit-on alors passé par un mix des 2 ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT pseudo FROM membres WHERE id_membre>$last_id LIMIT 20

Cela impose de passer le dernier id affiché en paramètre en cas de pagination.

[berceker united]

Concernant le limit. C'est bien mais au dela d'un certain nombre d'enregistrement ça peut pomper de la ressource. Une solution consistait a utiliser un IN(.....)
En gros il fallait récupérer la limite basse de l'id et la limite haute. L'intervale entre les deux te donne une liste d'id. Cette liste d'id tu le place dans un IN()...
Encor mieux avec une requete imbriqué.
SELECT * FROM maTable WHERE MonChamp IN(SELECT id FROM MaTable2 WHERE MonChamps BETWEEN 10 AND 20).

Il faut faire des test avec un gros nombre d'enregisrements entre l'utilisation du limit et celle cité ci-dessus avec le EXPLAIN SELECT ...

[dorian53]

Salut,

Ta réponse est malheureusement à coté du problème.

L'intérêt de la question traite le cas où l'on ne connait pas la limite haute ni basse pour définir le nombre d'id dans l'interval :/

[genova]

Pour répondre aux remarques deux pages plus tôt sur les guillements et simple quote, je trouve un peu étrange de parler d'optimisations à ce point ... Après tout PHP est un language interprété, il est totalement inutile d'optimiser ses scripts à la guillemet prèt. Si on veut de l'optimiser on fait du C ou un autre language moins interprété, mais a partir du moment où on code en PHP on est pas non plus a une microseconde prèt ..

[Invité(e)]

Pour répondre aux remarques deux pages plus tôt sur les guillements et simple quote, je trouve un peu étrange de parler d'optimisations à ce point ... Après tout PHP est un language interprété, il est totalement inutile d'optimiser ses scripts à la guillemet prèt. Si on veut de l'optimiser on fait du C ou un autre language moins interprété, mais a partir du moment où on code en PHP on est pas non plus a une microseconde prèt ..

Je suis d'accord avec toi , mais il faut savoir que suivant la popularité du site
que 1 microseconde par ici , 1 microseconde par la ca fait vite des seconces au final.

[genova]

Effectivement, si ton script fait 500Ko et que tu utilises toutes les lignes une " au lieu d'une ' tu gagneras peut être un millième de seconde en appliquant l'optimisation

Ce que je voulais dire c'est qu'il y a optimisations utiles, et optimisations inutiles. Un développeur qui connait parfaitement les optimisations microscopique de ce genre, mais qui n'est pas capable de créer un index corect sur sa base de donnée, aura des scripts hyper lent ... Les plus grosses optimisations en PHP ca reste du côté des requètes SQL, et aussi de la mise en cache des calculs assez imposants dans le genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if (!$result = cache_get('resultat'))
{
   $result = ... // Gros calcul
   cache_put('result', $result);
}

L'utilisation de variables statiques peut aussi être un gain de temps, par exemple si on a une fonction smiley() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
function smiley($str)
{
   static $smilies = null;
 
   if ($smilies === null)
   {
      // Récupération des smilies dans la database ou dans un répertoire
   }
 
   foreach ($smilies AS $origine => $replace)
   {
      $str = str_replace($origine, $replace, $str);
   }
   return ($str);
}