Discussion :

[Invité(e)]

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);
}

c'est vrai ca sert à rien non plus d'enc...u........r les mouches

[Sined_]

Bonjour !
Bonne idée ce forum, quelqu’un sait si :

Code :

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

elseif { … }

et

Code :

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

else if { … }

Ont une différence au niveau de la vitesse ?
Merci d’avance

[sekaijin]

Code :

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

SELECT pseudo FROM membres LIMIT 40,20

Solution optimisée...

Heu excusez du peux mais si MySQL ne sais pas en interne optimiser une telle requête il est bon pour la poubelle

car tous les SGBD que j'ai rencontrés parcourent l'index primaire de la table et limite l'index puis ensuite remonte les données et ceci si la table à un volume important car dans le cas contraire il est plus couteux de'utiliser un index et le moteur de lui même choisit de parcourir la table il est impossible sur un moteur évolué d'optimiser plus une telle requête.

l'explain de PostgreSQL est particulièrement claire pour comprendre la stratégie
créez deux table une à forte poulation lautre non et lancez un explain de cette requete sur les deux

l'optimisation de la requête dépends de l'usage statistique de la base et les moteurs adapte leur stratégie au fil du temps.

là ou vous allez pouvoir intervenir c'est sur l'optimisation de requêtes imbriquées

Code :

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

1
2
3
4
5
6
7
8
SELECT
 referencetable.*,
 CASE mt_id
  WHEN '25' THEN 't'
  ELSE 'f'
 END AS selected
FROM referencetable
LEFT JOIN (SELECT * FROM selecteditems WHERE mt_id = '25') AS list USING (rt_id)

ou

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
(SELECT
 referencetable.*,
 't' AS selected
FROM referencetable
INNER JOIN selecteditems USING (rt_id)
WHERE mt_id = '25')
UNION
(SELECT
 referencetable.*,
 'f' AS selected
FROM referencetable
LEFT JOIN selecteditems USING (rt_id)
WHERE mt_id <> '25')

les deux remonte la table "referencetable" complète avec un champs selected à 't' ou 'f' suivant que la ligne est référencé dans selecteditems pour l'id 25

mais la deuxième fait deux jointure sur les deux taable à lors que la première en fait qu'une. il y a bien deux select dans les deux
sur un bon moteur de base (orcle postgres Sqlserver ingre ...) les requêtes suivantes sont paraitement équivalente (l'explain done exactement la même stratégie)

Code :

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

1
2
3
4
SELECT
 referencetable.*
FROM referencetable
INNER JOIN (SELECT * FROM selecteditems WHERE mt_id = '25') AS list USING (rt_id)

ou

Code :

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

1
2
3
4
5
SELECT
 referencetable.*
FROM referencetable
INNER JOIN selecteditems USING (rt_id)
WHERE mt_id = '25'

ou

Code :

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

1
2
3
4
5
SELECT
 referencetable.*
FROM referencetable, selecteditems
WHERE mt_id = '25'
AND referencetable.rt_id = selecteditems.rt_id

Et heureusement car un SGBD est avant tout un moteur de calcul ensembliste s'il ne le faisait pas cela signifirait qu'il ne fait du calcul d'ensemle mais du calcul procedural

tout SGBD à des limite et j'espere que MySQL fait pareil sion c'est grave.
déjà qu'il ne sait pas faire un truc aussi simple que le B-A-BA des jointures multiples

Code :

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

1
2
3
4
5
6
SELECT *
FROM table_principale
INNER JOIN table_ref1 USING (tr1_id)
INNER JOIN table_ref2 USING (tr2_id)
INNER JOIN table_ref3 USING (tr3_id)
INNER JOIN table_ref3 USING (tr4_id)

Ou la table principale contient les id tr1_id,tr2_id,tr3_id,tr4_id
MySQL ne sais pas ordoner ses jointures pour obtenir le résultat ce qui est une grave lacune.
dans un cas pareils il faut en passer par une forme en WHERE (qui en théorie sont équivalentes. visiblement pas pour MySQL) et c'est développeur d'optimiser l'ordres des jointures alors que cela peux dépendre au fil du temps et de la charge des tables

A+JYT

[berceker united]

Bonjour !
Bonne idée ce forum, quelqu’un sait si :

Code :

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

elseif { … }

et

Code :

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

else if { … }

Ont une différence au niveau de la vitesse ?
Merci d’avance

je pense que elseif est plus optimisé. Déjà il est prévus pour. Pour l'autre je pense que ça lui fait un embriquement de zone de condition et c'est le faite d'embriquer les bloques de condition qui prend plus de mémoire. Mais l'un ou l'autre le gain n'est pas vraiment quantifiable. Il faut plus coder avec bon sens que de chercher des µ secondes qui ne servent à rien.

[genova]

J'en doute ... le parseur PHP interprète très probablement else if et elseif comme un seul et même token.

[sekaijin]

J'en doute ... le parseur PHP interprète très probablement else if et elseif comme un seul et même token.

exatement
je pense même que le compilateur (car il y en) a un doit produire le même code que pour

Code :

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

1
2
3
4
5
if () {
} else {
 if () {
 } 
}

Je n'en mettrais pa sma main à coupé il y a tent de truc bizare dans le compilo zend
mais en général les compilateur produise le même code pour les trois syntaxe
et ç me parait normal
A+JYT

[Metallic-84s]

Test #1

Code :

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

1
2
3
for ($i = 0; $i < 4000000; $i++) {
    echo 'TEXT';
}

Test #2

Code :

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

1
2
3
4
5
$echo = '';
for ($i = 0; $i < 4000000; $i++) {
    $echo .= 'TEXT';
}
echo $echo;

Résultats
Le test #2 est généré trois à quatre fois plus rapidement !

Ainsi, il est plus judicieux de mettre en place un système de cache d'affichage, plutôt que de multiplier les "echo". A cet effet, PHP met à notre disposition :

ob_start();
ob_end_flush();

Ainsi, le code ci-dessous sera (plus ou moins) équivalent et tout aussi rapide que notre test #2.

Code :

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

1
2
3
4
5
ob_start();
for ($i = 0; $i < 4000000; $i++) {
    echo 'TEST';
}
ob_end_flush();

[berceker united]

Test #1

Code :

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

1
2
3
for ($i = 0; $i < 4000000; $i++) {
    echo 'TEXT';
}

Test #2

Code :

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

1
2
3
4
5
$echo = '';
for ($i = 0; $i < 4000000; $i++) {
    $echo .= 'TEXT';
}
echo $echo;

Résultats
Le test #2 est généré trois à quatre fois plus rapidement !

Ainsi, il est plus judicieux de mettre en place un système de cache d'affichage, plutôt que de multiplier les "echo". A cet effet, PHP met à notre disposition :

ob_start();
ob_end_flush();

Ainsi, le code ci-dessous sera (plus ou moins) équivalent et tout aussi rapide que notre test #2.

Code :

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

1
2
3
4
5
ob_start();
for ($i = 0; $i < 4000000; $i++) {
    echo 'TEST';
}
ob_end_flush();

En faite, ce que tu avances à des limites. En effet ça depend de ce que la variable mange comme texte à chaque boucle. Car plus la boucle avance plus cela va ralentire le systeme. J'ai constaté ce phénomène en php ainsi qu'en C#. A chaque fois qu'il y a une boucle il est obligé de ranger les informations dans la variable donc la mémoire.

[Yogui]

C'est toujours le même compromis : augmenter la mise en cache améliore les performances mais augmente la consommation de mémoire (et complique souvent le code). Je pense que ce n'est pas à ce niveau qu'il faut chercher l'optimisation, d'ailleurs il ne faut pas chercher l'optimisation mais le code lisible (donc pérenne).

Apprenez à utiliser un framework : cela fera baisser les perfs de votre site mais au moins vous vous y retrouverez d'une année sur l'autre, sans devoir vous gratter la tête en relisant votre ancien code (j'en vois qui se reconnaissent)


Je prône les perfs en qualité plutôt qu'en temps d'exécution. De toute manière, les serveurs sont généralement surdimesionnés et c'est habituellement la base de données qui ralentit l'application, pas les boucles en PHP.

[sekaijin]

C'est toujours le même compromis : augmenter la mise en cache améliore les performances mais augmente la consommation de mémoire ....
Je prône les perfs en qualité plutôt qu'en temps d'exécution. De toute manière, les serveurs sont généralement surdimesionnés et c'est habituellement la base de données qui ralentit l'application, pas les boucles en PHP.

Je suis bien d'accord avec la première partie
mais pas du tout avec la deuxième.
bien trop souvent on vois écrit en php ce que la base sait faire avec des perf très largement suppérieures.

personnellement je n'ai jamais eu de ralentissement due à ma base. et pourtant il m'arrive dans une seule requête de brasser pluseirus dixaine de table de plusieur millons d'enregistrement pour certaines.
les temps de réponse sont bien inférieur à la même chose fait en php avec de multiples accès.

alors mieux vait solliciter la base correctement que de faire des boucles php
j'ai un exemple d'une requête qui remonte toujours exactement 25 lignes de 4 collones mais pour y arriver elle brasse 15 tables avec des calculs et intersection de plages horaires sur des milliers d'enregistrement.
ma boucle fait 24 itération et la base réponds en quelques secondes. si je devais solliciter la base et faire toutes les boucles pour croiser mes données et faire mes calcul en php je passerais à coup sur les time out.

écrire une bonne structure de base et des requête cohérentes est un gage de perf. bien plus que toutes les boucles optimisé imaginable en php.

A+JYT

[Yogui]

Si tu relis ce que j'ai écrit, nous somems parfaitement d'accord : coder correctement est un meilleur gage de performances que chercher la petite bête. En plus, ça fait du code plus facile à maintenir.

[Seb33300]

A prioris ça n'a pas été posté

Plutot que de faire :

Code :

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

1
2
3
4
5
6
7
8
$req = mysql_query("SELECT COUNT(*) as nb FROM `table` WHERE `id`=".$id);
$rslt = mysql_fetch_array($req);
 
if($rslt['nb'] > 0){
     mysql_query("UPDATE `table` SET `time`=".time()." WHERE `id`=".$id);
}else{
     mysql_query("INSERT INTO `table` (`id`, `time`) VALUES ('$id', '".time()."')");
}

Faire :

Code :

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

mysql_query("INSERT INTO `table` (`id`, `time`) VALUES ('$id', '".time()."') ON DUPLICATE KEY UPDATE `time`='".time()."');

Bien sur cela implique d'avoir mis le champ `id` en clé primaire

[Yogui]

Pour info, MySQL propose la clause REPLACE INTO, dont la syntaxe est identique à l'INSERT INTO

[Seb33300]

Manuel Mysql

REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserted. See Section 13.2.4, “INSERT Syntax”.

Donc dans les tables InnoDB avec suppression en cascade on se retrouve à supprimer tous les contenus des autres table du meme ID.
Alors que le ON DUPLICATE KEY fait un UPDATE

[genova]

Le ON DUPLICATE KEY marche à partir de quelle version de MySQL ? Marche postGreSQL et SQLite ?

[Seb33300]

A partir de MySQL 4.1.

Et je pense que c'est spécifique à MySQL

http://www.estvideo.com/dew/index/20...ate-key-update

[Kioo]

Ca marche seuleument avec les tables InnoDB me semble-t-il...

Pour revenir sur le LIMIT et le BETWEEN:

Pour ma part je ne vois pas le même résultat entre les 2 requêtes.
L'une est executée par rapport "aux lignes de la table", l'autre par rapport à l'id.
Me tromperai-je ????

[berceker united]

Ca marche seuleument avec les tables InnoDB me semble-t-il...

Pour revenir sur le LIMIT et le BETWEEN:

Pour ma part je ne vois pas le même résultat entre les 2 requêtes.
L'une est executée par rapport "aux lignes de la table", l'autre par rapport à l'id.
Me tromperai-je ????

Oui et non. En faite le between n'a pas de rapport sur leur but. L'un te donne un certain nombre de résultat par rapport à un point de départ. Les valeurs n'ont pas besoin d'être connu. Le Between retourne un jeux de resultat suivant un altervale entre deux numérique ou date. Donc la valeur à besoin d'être connu.
Mais pour des raisons de performance les deux peuvent servir pour émuler un limit beaucoup moin gourmant. Imaginez que tu dois faire un limit sur une table ayant plus de 100 000 enregistrements. Le LIMIT va ramer si tu lui demande 10 par 10 arrivé dans le 90 000eme enregistrement.
Le truc c'est de faire un limite uniquement sur une clé unique. A partir de ce jeux de resultat tu prend la premiere et la derniere et tu le place dans le Between. Mais maintenant nous nous rendons compte que vu que nous avons les 10 id nous pouvons tous simplement utiliser un IN(...)
Cette astuce est utilisé sur les gros forum français.

[genova]

berceker united tu pourrais développer un peu plus l'optimisation du LIMIT + BETWEEN ? Ca m'interesse beaucoup, mais j'ai pas saisi dans l'intégralité le raisonement.

Sinon à la question LIMIT = BETWEEN ? Bien sur que non. LIMIT est appliqué sur le résultat, alors que BETWEEN est un filtre et sert donc à calculer le résultat.

Le problème de BETWEEN, c'est que si par exemple tu as supprimé des entrées, et que tu as des "trous" dans tes ID, il te renverra moins de résultats que prévu, alors que LIMIT renverra les X résultats que tu demandes.

[berceker united]

berceker united tu pourrais développer un peu plus l'optimisation du LIMIT + BETWEEN ? Ca m'interesse beaucoup, mais j'ai pas saisi dans l'intégralité le raisonement.

Sinon à la question LIMIT = BETWEEN ? Bien sur que non. LIMIT est appliqué sur le résultat, alors que BETWEEN est un filtre et sert donc à calculer le résultat.

Le problème de BETWEEN, c'est que si par exemple tu as supprimé des entrées, et que tu as des "trous" dans tes ID, il te renverra moins de résultats que prévu, alors que LIMIT renverra les X résultats que tu demandes.

Lorsqu'il y a une requête pouvant retourner plusieurs champs dont les tables possède énormément d'enregistrements, l'utilisation d'un LIMIT peut être catastrophique point de vue performance. Plus le curseur de départ du LIMIT s'éloigne du début des enregistrements plus les performances se dégrade.
Dans ce genre d'opération il faut faire l'opération en deux temps.
Premier temps faire une requête récupérant que l'id avec le LIMIT.

Code :

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

SELECT id FROM forum LIMIT 65412, 10;

Resultat:
id de 125455 ... 125465

Second temps, avec le jeux de resultat avec juste les id vous faite ceci.

Code :

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

SELECT * FROM forum id BETWEEN 125455 AND 125465

ou

Code :

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

SELECT * FROM forum id IN(125455,125456,125457,...,125465)

Pas de problème de trou parce celui sera automatiquement comblé vie le LIMIT qui lui va toujours retourner le même nombre de résultat sauf à la fin.