8792 sujets

Développement web côté serveur, CMS

Optimisation de conditions

Pages :
(reprise du message précédent)

Peut-être, mais de mon côté, j'optimise en utilisant microtime() appliqué à des structures objets pour détecter les portions de code que peuvent ralentir le serveur.
J'ai certains script qui effectuent des manipulations d'images ou des calculs complexes ou des analyses de code source (notament avec des expressions régulières un peu pointues), ainsi que des transformations xslt, etc etc.., et je ressent parfois le besoin de me faire une idée.
Je n'appelle pas ça bench, mais mesure, et je suis tout à fait conscient des différences qu'il peut y avoir entre deux machines, deux versions de php, deux systèmes d'exploitation. Tout cela est basique.
L'interêt est de comparer deux fonctions dans la même environnement et de déduire que l'une est plus efficace que l'autre. Soit un peu plus, beaucoup plus...
Rien à voir avec les switch. La seule galerie que j'amuse, c'est moi-même.
GeorgesM a écrit :
analyses de code source (notament avec des expressions régulières un peu pointues)
Arf... les expressions régulières ! Smiley langue
GeorgesM a écrit :
Peut-être, mais de mon côté, j'optimise en utilisant microtime() appliqué à des structures objets pour détecter les portions de code que peuvent ralentir le serveur.

Le problème de cette méthode, est qu'elle est particulièrement inefficiente, difficile de vraiment cerner ce qui est lent.

Le mieux est d'utiliser une extension PHP type xDebug, fournissant un vrai profiler. Couplé à KCacheGrind (ou WinCacheGrind sous win), on voit facilement ce qui est lent ou pas, exemple :
http://img187.imageshack.us/img187/6176/profilell1.th.png
a écrit :
Le problème de cette méthode, est qu'elle est particulièrement inefficiente, difficile de vraiment cerner ce qui est lent.


Objectivement, pourquoi ?

En l'occurence, il s'agit de comparer deux bouts de codes de moins de 20 lignes qui s'exécutent en moins de 300 micro-secondes (sur mon pentium III). Un profiler aurait du mal à mesurer des durées aussi courtes.

Et puis, pourquoi on ne reste pas sur le sujet ?
Modifié par GeorgesM (06 Nov 2006 - 09:01)
GeorgesM a écrit :
Objectivement, pourquoi ?

En l'occurnce, il s'agit de comparer deux bouts de codes de moins de 20 lignes qui s'exécutent en moins de 300 micro-secondes (sur mon pentium III). Un profiler aurait du mal à mesurer des durées aussi courtes.

Parce qu'il ne faut jamais analyser juste un petit bout comme ça hors contexte, on risque de s'attarder sur quelque chose alors qu'il y a plus important à optimiser Smiley smile D'où l'interêt du profiler qui fait pareil, mais sur l'ensemble de l'application

Je sais plus qui a écrit :
Premature optimization is the root of all evil
Encore faut-il qu'il y ait un contexte.
Dans le cas qui nous occupe, il s'agit simplement de comparer les performances de deux fonctions.
Il n'y a pas de contexte.
C'est là où ça peut justement être dangereux Smiley lol Benchmarker une fonction, passer des plombes à tenter de l'optimiser, alors qu'au final elle risque de se retrouver dans une application entière où il y aurait des choses plus importantes à optimiser...
C'est bien pour ça que je dis que les benchs comme on les voit partout, c'est de la rigolade.

C'est comme ceux qui crient haut et fort et sans distinction que les regex c'est lent.
En général, c'est vrai, mais pas tout le temps.
J'ai vu de boucles bien plus lente qu'un simple preg_match_all
Salut,

Je viens de découvrir ce sujet, si j'ai bien compris le premier post, ChrisG cherche un moyen de créer les conditions SQL à partir de valeurs GET. D'après ce que je vois dans le premier post, on n'autorise que "annee", "annee + mois" et "annee + mois + jour" c'est ça ? (autrement dit, pas de "annee + jour" ou "mois + jour")

Que penses-tu de ça, ça devrait correspondre exactement à ce que je viens de décrire :
$vars = array(
	'annee'	=>	'YEAR',
	'mois'	=>	'MONTH',
	'jour'	=>	'DAYOFMONTH'
);

$where = array();
foreach ($vars as $var => $func)
{
	if (isset($_GET[$var]) && ctype_digit($_GET[$var]))
	{
		// La variable existe et il s'agit bien d'un nombre
		$where[] = $func . '(date) = ' . $_GET[$var];
	}
	else
	{
		// La variable n'existe pas, on s'arrête là
		break;
	}
}

$period = (empty($where)) ? '' : 'WHERE ' . implode(' AND ', $where);

Les différences par rapport au code du premier post :
- les valeurs sont vérifiées, pas d'injection SQL
- pas d'apostrophes autour des nombres (facultatifs)

En parlant d'optimisation, en y réfléchissant je ne pense pas que MySQL utilise les indices (pour peu que tu en aies défini un) pour la comparaison de la date vis-à-vis du résultat de la fonction. Tu devrais peut-être essayer avec LIKE à la place. Par exemple, tous les articles du mois de novembre 2006:
SELECT * FROM table WHERE date LIKE '2006-11-%'
Après vérification, je confirme qu'il faut utiliser LIKE si on veut avoir une chance d'utiliser l'index de la colonne. (uniquement si l'année est définie, sinon de toutes façons MySQL fera un scan complet de la table)

En plus, en relisant le premier post je m'aperçois que toutes les combinaisons d'année/mois/jour sont autorisées, donc voici une "mise à jour". Désolé pour les ternaires, c'est plus court :]
$vars = array('annee', 'mois', 'jour');

$date = array();
foreach ($vars as $var)
{
	$date[] = (isset($_GET[$var]) && ctype_digit($_GET[$var])) ? $_GET[$var] : '%';
}

$date = implode('-', $date);
$period = ($date == '%-%-%') ? '' : "WHERE date LIKE '" . $date . "'";


Edit: corrigé le $_GET['var']
Modifié par Hubert Roksor (15 Nov 2006 - 22:30)
Hum, cette ligne est fausse ($_GET['var'])

$date[] = (isset($_GET[$var]) && ctype_digit($_GET[$var])) ? $_GET['var'] :

Je pense qu'il faut lire $_GET[$var]

... et ça donne:

$date = array();
foreach (array('annee', 'mois', 'jour') as $var)
	$date[] = (isset($_GET[$var]) && ctype_digit($_GET[$var])) ? $_GET[$var] : '%';

$date = implode('-', $date);
$period = ($date == '%-%-%') ? '' : "WHERE date LIKE '" . $date . "'";


Soit quatre lignes, difficile de faire mieux. Smiley clapclap
Modifié par GeorgesM (15 Nov 2006 - 21:30)

désolé pour le message à retardement...J'avais zappé la seconde page...

Bonjour !

Bison,dans ton exemple sur le switch, il est évident que le tableau est plus performant.

Mais tu as des cas où le switch est plus pratique. Si tu as des fonctions ou une floppée de codes à exécuter selon tes cas, je vois pas bien comment ton tableau peut simplifier la chose.

Un cas où tu as une nombre de choix limité (des constantes par exemple).

switch($truc){

case CHX_1:
     fonction1();     
     fonction2(); 
     ...
     fonctionN();
break;
case CHX_2:
     fonction1();     
     fonction2(); 
     ...
     fonctionN();
break;
...
case CHX_N:
     fonction1();     
     fonction2(); 
     ...
     fonctionN();
break;
}

Dans un cas comme ça, un switch est plus lisible à mon gout que des if et les tableaux ne peuvent en rien gérer ça.

Qu'en pensez vous ? Smiley edit Modifié par Zeke (15 Jan 2007 - 08:56)[/edit]
Je n'ai pas dit que le switch() n'avait pas sa place, j'ai dit que dans 99% des cas, il peut avantageusement être remplacé par un array()

Chaque fois que j'ai eu à débattre à propos du switch, ça a toujours été dans le cadre d'un affichage de page dans un système d'include ou du passage de valeurs simples dans les positions.

Bien que je n'en ai jamais eu besoin dans les dizaines de dev que j'ai traité, le switch existe et dans le cadre de fonctions ou de multi-argument, il sera sans doute utilisable.
Bison a écrit :

Chaque fois que j'ai eu à débattre à propos du switch, ça a toujours été dans le cadre d'un affichage de page dans un système d'include ou du passage de valeurs simples dans les positions.


C'est clair que dans ce genre de situation, le switch n'est pas nécessaire.
Il est vrai que le switch est très souvent utilisé dans dans cas où l'on pourrait sans problème sans passer.
Smiley smile
Bison a écrit :
dans le cadre d'un affichage de page dans un système d'include ou du passage de valeurs simples dans les positions.


tu peux donner deux ptis exemples pour que je visualise ?
Pages :
Sujet clos
Aller à