Controle de la qualité d'un code : y'a-t-il de bons softs ?
40 réponses
Qbm
Bonjour tout le monde,
Je cherche un soft (sous licence libre de préférence) qui puisse me
fournir des infos sur la qualité de mon code C++. En java, javancss le
fait très bien, mais en C++ j'y connaîs pas grand chose.
J'ai donc parcouru un peu le net avant de poster ici, mais je n'ai pas
trouvé beaucoup d'avis d'utilisateurs. J'aimerais donc savoir quel(s)
logiciel(s) utilisez vous ?
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier
la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère que qualité. Mais ce n'est pas ce que mesure un profiler. Un profiler a pour but de localiser les bottleneck, en faisant des mesures d'une granularité bien plus faible que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas un outil de *mesure* du critère de qualité "temps d'exécution", mais un outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
Je ne connais pas gprof mais les profilers que j'ai utilisés donnent aussi bien des mesures locales que des mesures plus globales (graphe d'appels + additions des temps...) Dans un certain nombre de cas le profiler peut donner le temps perçu global *et* le bottleneck local.
Ceci étant dit, il est certain que dans le cas d'un code comportant pas mal d'I/O, le CPU consommé peut être insignifiant par rapport au temps perçu par l'utilisateur et donc le profiler ne sert pour ainsi dire à rien.
Loïc Joly wrote:
Olivier Azeau wrote:
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "noone@nowhere.com"
<noone@nowhere.com>:
gprog
[gprof]
A quoi sert-il exactement dans ce cas précis ?
Il me semble que gprof est un profiler, i.e. un programme qui permet
de savoir où optimiser le code (ce qui peut vouloir dire sacrifier
la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon
critere de qualité ?
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au
sens large peut être un bon critère que qualité. Mais ce n'est pas ce
que mesure un profiler. Un profiler a pour but de localiser les
bottleneck, en faisant des mesures d'une granularité bien plus faible
que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas
un outil de *mesure* du critère de qualité "temps d'exécution", mais un
outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
Je ne connais pas gprof mais les profilers que j'ai utilisés donnent
aussi bien des mesures locales que des mesures plus globales (graphe
d'appels + additions des temps...)
Dans un certain nombre de cas le profiler peut donner le temps perçu
global *et* le bottleneck local.
Ceci étant dit, il est certain que dans le cas d'un code comportant pas
mal d'I/O, le CPU consommé peut être insignifiant par rapport au temps
perçu par l'utilisateur et donc le profiler ne sert pour ainsi dire à rien.
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier
la
lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère que qualité. Mais ce n'est pas ce que mesure un profiler. Un profiler a pour but de localiser les bottleneck, en faisant des mesures d'une granularité bien plus faible que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas un outil de *mesure* du critère de qualité "temps d'exécution", mais un outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
Je ne connais pas gprof mais les profilers que j'ai utilisés donnent aussi bien des mesures locales que des mesures plus globales (graphe d'appels + additions des temps...) Dans un certain nombre de cas le profiler peut donner le temps perçu global *et* le bottleneck local.
Ceci étant dit, il est certain que dans le cas d'un code comportant pas mal d'I/O, le CPU consommé peut être insignifiant par rapport au temps perçu par l'utilisateur et donc le profiler ne sert pour ainsi dire à rien.
Olivier Azeau
Matthieu Moy wrote:
Olivier Azeau writes:
Et personne travaillant sur ce code n'avait identifié le problème sans outil ? j'en doute...
La situation décrite est, en carricaturant un peu : « du code écrit par des incompétents repris ou évalué par des gens compétents ». Ce genre de cas est AMHA assez fréquent ... Les outils ne changeront pas forcément les premiers, mais ils feront gagner du temps aux seconds.
En caricaturant encore plus, on peut ajouter que la compétence c'est aussi savoir ne pas reprendre du code qui n'amène que des problèmes :-)
Matthieu Moy wrote:
Olivier Azeau writes:
Et personne travaillant sur ce code n'avait identifié le problème sans
outil ? j'en doute...
La situation décrite est, en carricaturant un peu : « du code écrit
par des incompétents repris ou évalué par des gens compétents ». Ce
genre de cas est AMHA assez fréquent ... Les outils ne changeront pas
forcément les premiers, mais ils feront gagner du temps aux seconds.
En caricaturant encore plus, on peut ajouter que la compétence c'est
aussi savoir ne pas reprendre du code qui n'amène que des problèmes :-)
Et personne travaillant sur ce code n'avait identifié le problème sans outil ? j'en doute...
La situation décrite est, en carricaturant un peu : « du code écrit par des incompétents repris ou évalué par des gens compétents ». Ce genre de cas est AMHA assez fréquent ... Les outils ne changeront pas forcément les premiers, mais ils feront gagner du temps aux seconds.
En caricaturant encore plus, on peut ajouter que la compétence c'est aussi savoir ne pas reprendre du code qui n'amène que des problèmes :-)
Olivier Azeau
Fabien LE LEZ wrote:
On Tue, 25 Jan 2005 21:44:47 +0100, Loïc Joly :
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère de qualité.
Et encore, critère de qualité de l'application dans son ensemble, pas vraiment qualité du code (i.e. lisibilité, simplicité, facilité d'évolution, etc.)
Ca dépend. Un facteur de ralentissement que j'ai déjà rencontré (et détecté avec un profiler) c'est une utilisation abusive d'allocations dans le tas qui est, je pense, un problème de qualité de code.
Fabien LE LEZ wrote:
On Tue, 25 Jan 2005 21:44:47 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr>:
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au
sens large peut être un bon critère de qualité.
Et encore, critère de qualité de l'application dans son ensemble, pas
vraiment qualité du code (i.e. lisibilité, simplicité, facilité
d'évolution, etc.)
Ca dépend. Un facteur de ralentissement que j'ai déjà rencontré (et
détecté avec un profiler) c'est une utilisation abusive d'allocations
dans le tas qui est, je pense, un problème de qualité de code.
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère de qualité.
Et encore, critère de qualité de l'application dans son ensemble, pas vraiment qualité du code (i.e. lisibilité, simplicité, facilité d'évolution, etc.)
Ca dépend. Un facteur de ralentissement que j'ai déjà rencontré (et détecté avec un profiler) c'est une utilisation abusive d'allocations dans le tas qui est, je pense, un problème de qualité de code.
Fabien LE LEZ
On Tue, 25 Jan 2005 22:35:34 +0100, Olivier Azeau :
En caricaturant encore plus, on peut ajouter que la compétence c'est aussi savoir ne pas reprendre du code qui n'amène que des problèmes :-)
Malheureusement, on n'a pas toujours le temps de tout recoder soi-même :-(
-- ;-)
On Tue, 25 Jan 2005 22:35:34 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:
En caricaturant encore plus, on peut ajouter que la compétence c'est
aussi savoir ne pas reprendre du code qui n'amène que des problèmes :-)
Malheureusement, on n'a pas toujours le temps de tout recoder soi-même
:-(
| Je n'ai jamais vu une mésure de complexité qui prenait en | compte le pourcentage des commentaires.
Mais cela ne veut pas dire que cela n'existe pas pour autant :-)
Tu es connais, toi ? Je serais curieux comment elle s'y prendrait.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Loïc Joly wrote:
Olivier Azeau wrote:
Comme divers autres intervenants, je ne vois pas en quoi ce genre de statistiques peut donner une mesure de qualité intrinseque sur du code.
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions.
Il te faut un outil pour trouver ça ? La revue du code n'a rien dit ?
Je suis convaincu en ce qui concerne l'utilité des telles mésures. Mais je ne les crois pas une panacée non plus ; elles n'ont de l'utilité que dans le cadre d'un processus de développement bien défini, qui comprend aussi des revues de code, des tests unitaires, ...
Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils peuvent servir à trois choses :
- Quand on doit prendre en main un code fait par d'autres, avoir une idée de l'étendue des dégats, afin d'évaluer rapidement le temps de prise en main qui sera nécessaire.
Voire s'il ne vaut mieux carrément le jeter à la poubelle. Avec les fonctions de plus de 2000 lignes et avec une complexité cyclotomatique de l'ordre de 100, il serait probablement moins cher de développer quelque chose de neuf que d'essayer la moindre modification.
- Servir d'argument massue lors d'une recette (pour du code fait en externe). Il est en effet difficile de spécifier dans un cahier des charges qu'on veut du beau code, car c'est sujet à goûts et débats d'idée (à moins peut-être de définir un organisme externe aux deux parties chargé d'arbitrer). Spécifier de tels éléments de mesure certes ne garanti en rien la qualité du résultat, mais permet d'éliminer un type de non qualité, et c'est toujours ça de pris.
Gérer des préstataires est toujours un problème dans un processus de développement. À la longue, la seule solution que je connais, c'est d'évaluer la qualité livrée avec tous les moyens disponibles (mésures de complexité, mais aussi revue du code et évaluation des statistiques sur les erreurs qui y apparaissent par la suite), et d'écarter les fournisseurs dont la qualité n'est pas suffisante.
- Si on remarque que sur plusieurs projets du même type, on trouve pour une équipe des corrélations entre divers paramètres, ça peut être une voie de progrès pour cette équipe (par exemple, si le ratio entre complexité d'une fontion et nombre de bugs trouvé dedans est constant, c'est une bonne motivation pour inciter une équipe à diminuer la complexité de ses fonctions).
C'est effectivement un bon outil pour mésurer le progrès des équipes. Parmi d'autres, évidemment, mais il a l'avantage de donner un feed-back immédiate, tandis que une diminuation dans le taux d'erreurs ne se constate que par la suite.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote:
Olivier Azeau wrote:
Comme divers autres intervenants, je ne vois pas en quoi ce
genre de statistiques peut donner une mesure de qualité
intrinseque sur du code.
Dans du vrai code, au boulot, ce genre de mesure a permi
d'identifier une classe définie en plusieurs milliers de
lignes, avec plusieurs fonctions de plus de 2000 lignes
(certaines de 10000 je crois), une complexité cyclotomatique
de l'ordre de 100 dans pas mal de fonctions.
Il te faut un outil pour trouver ça ? La revue du code n'a rien
dit ?
Je suis convaincu en ce qui concerne l'utilité des telles
mésures. Mais je ne les crois pas une panacée non plus ; elles
n'ont de l'utilité que dans le cadre d'un processus de
développement bien défini, qui comprend aussi des revues de
code, des tests unitaires, ...
Eh bien, je trouve que ces chiffres indiquent un problème, et
qu'ils peuvent servir à trois choses :
- Quand on doit prendre en main un code fait par d'autres,
avoir une idée de l'étendue des dégats, afin d'évaluer
rapidement le temps de prise en main qui sera nécessaire.
Voire s'il ne vaut mieux carrément le jeter à la poubelle. Avec
les fonctions de plus de 2000 lignes et avec une complexité
cyclotomatique de l'ordre de 100, il serait probablement moins
cher de développer quelque chose de neuf que d'essayer la
moindre modification.
- Servir d'argument massue lors d'une recette (pour du code
fait en externe). Il est en effet difficile de spécifier dans
un cahier des charges qu'on veut du beau code, car c'est sujet
à goûts et débats d'idée (à moins peut-être de définir un
organisme externe aux deux parties chargé d'arbitrer).
Spécifier de tels éléments de mesure certes ne garanti en rien
la qualité du résultat, mais permet d'éliminer un type de non
qualité, et c'est toujours ça de pris.
Gérer des préstataires est toujours un problème dans un
processus de développement. À la longue, la seule solution que
je connais, c'est d'évaluer la qualité livrée avec tous les
moyens disponibles (mésures de complexité, mais aussi revue du
code et évaluation des statistiques sur les erreurs qui y
apparaissent par la suite), et d'écarter les fournisseurs dont
la qualité n'est pas suffisante.
- Si on remarque que sur plusieurs projets du même type, on
trouve pour une équipe des corrélations entre divers
paramètres, ça peut être une voie de progrès pour cette équipe
(par exemple, si le ratio entre complexité d'une fontion et
nombre de bugs trouvé dedans est constant, c'est une bonne
motivation pour inciter une équipe à diminuer la complexité de
ses fonctions).
C'est effectivement un bon outil pour mésurer le progrès des
équipes. Parmi d'autres, évidemment, mais il a l'avantage de
donner un feed-back immédiate, tandis que une diminuation dans
le taux d'erreurs ne se constate que par la suite.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Comme divers autres intervenants, je ne vois pas en quoi ce genre de statistiques peut donner une mesure de qualité intrinseque sur du code.
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions.
Il te faut un outil pour trouver ça ? La revue du code n'a rien dit ?
Je suis convaincu en ce qui concerne l'utilité des telles mésures. Mais je ne les crois pas une panacée non plus ; elles n'ont de l'utilité que dans le cadre d'un processus de développement bien défini, qui comprend aussi des revues de code, des tests unitaires, ...
Eh bien, je trouve que ces chiffres indiquent un problème, et qu'ils peuvent servir à trois choses :
- Quand on doit prendre en main un code fait par d'autres, avoir une idée de l'étendue des dégats, afin d'évaluer rapidement le temps de prise en main qui sera nécessaire.
Voire s'il ne vaut mieux carrément le jeter à la poubelle. Avec les fonctions de plus de 2000 lignes et avec une complexité cyclotomatique de l'ordre de 100, il serait probablement moins cher de développer quelque chose de neuf que d'essayer la moindre modification.
- Servir d'argument massue lors d'une recette (pour du code fait en externe). Il est en effet difficile de spécifier dans un cahier des charges qu'on veut du beau code, car c'est sujet à goûts et débats d'idée (à moins peut-être de définir un organisme externe aux deux parties chargé d'arbitrer). Spécifier de tels éléments de mesure certes ne garanti en rien la qualité du résultat, mais permet d'éliminer un type de non qualité, et c'est toujours ça de pris.
Gérer des préstataires est toujours un problème dans un processus de développement. À la longue, la seule solution que je connais, c'est d'évaluer la qualité livrée avec tous les moyens disponibles (mésures de complexité, mais aussi revue du code et évaluation des statistiques sur les erreurs qui y apparaissent par la suite), et d'écarter les fournisseurs dont la qualité n'est pas suffisante.
- Si on remarque que sur plusieurs projets du même type, on trouve pour une équipe des corrélations entre divers paramètres, ça peut être une voie de progrès pour cette équipe (par exemple, si le ratio entre complexité d'une fontion et nombre de bugs trouvé dedans est constant, c'est une bonne motivation pour inciter une équipe à diminuer la complexité de ses fonctions).
C'est effectivement un bon outil pour mésurer le progrès des équipes. Parmi d'autres, évidemment, mais il a l'avantage de donner un feed-back immédiate, tandis que une diminuation dans le taux d'erreurs ne se constate que par la suite.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Fabien LE LEZ wrote:
On Tue, 25 Jan 2005 22:35:34 +0100, Olivier Azeau :
En caricaturant encore plus, on peut ajouter que la compétence c'est aussi savoir ne pas reprendre du code qui n'amène que des problèmes :-)
Malheureusement, on n'a pas toujours le temps de tout recoder soi-même :-(
Dans le cas que Loïc a décrit, c'est probable que le temps de tout récoder soit inférieur au temps nécessaire pour essayer de maintenir le bordel qu'il y avait.
C'est le vieux question : si on n'a pas le temps de le faire correctement, comment va-t-on trouver le temps de le faire une deuxième fois ? Tôt ou tard, il va falloir y passer. Donc, tout le temps dépensé sur la version actuelle est du temps perdu.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Tue, 25 Jan 2005 22:35:34 +0100, Olivier Azeau
<read.my.name.and.email.to.firstname@lastname.com>:
En caricaturant encore plus, on peut ajouter que la
compétence c'est aussi savoir ne pas reprendre du code qui
n'amène que des problèmes :-)
Malheureusement, on n'a pas toujours le temps de tout recoder
soi-même :-(
Dans le cas que Loïc a décrit, c'est probable que le temps de
tout récoder soit inférieur au temps nécessaire pour essayer de
maintenir le bordel qu'il y avait.
C'est le vieux question : si on n'a pas le temps de le faire
correctement, comment va-t-on trouver le temps de le faire une
deuxième fois ? Tôt ou tard, il va falloir y passer. Donc, tout
le temps dépensé sur la version actuelle est du temps perdu.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Tue, 25 Jan 2005 22:35:34 +0100, Olivier Azeau :
En caricaturant encore plus, on peut ajouter que la compétence c'est aussi savoir ne pas reprendre du code qui n'amène que des problèmes :-)
Malheureusement, on n'a pas toujours le temps de tout recoder soi-même :-(
Dans le cas que Loïc a décrit, c'est probable que le temps de tout récoder soit inférieur au temps nécessaire pour essayer de maintenir le bordel qu'il y avait.
C'est le vieux question : si on n'a pas le temps de le faire correctement, comment va-t-on trouver le temps de le faire une deuxième fois ? Tôt ou tard, il va falloir y passer. Donc, tout le temps dépensé sur la version actuelle est du temps perdu.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 26 Jan 2005 03:11:31 -0800, :
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions.
Il te faut un outil pour trouver ça ? La revue du code n'a rien dit ?
A priori, l'idée est de passer l'outil de mesure dès qu'on reçoit le code, afin d'avoir en quelques minutes une idée de l'étendue des dégâts. La revue de code ne vient qu'après.
-- ;-)
On 26 Jan 2005 03:11:31 -0800, kanze@gabi-soft.fr:
Dans du vrai code, au boulot, ce genre de mesure a permi
d'identifier une classe définie en plusieurs milliers de
lignes, avec plusieurs fonctions de plus de 2000 lignes
(certaines de 10000 je crois), une complexité cyclotomatique
de l'ordre de 100 dans pas mal de fonctions.
Il te faut un outil pour trouver ça ? La revue du code n'a rien
dit ?
A priori, l'idée est de passer l'outil de mesure dès qu'on reçoit le
code, afin d'avoir en quelques minutes une idée de l'étendue des
dégâts. La revue de code ne vient qu'après.
Dans du vrai code, au boulot, ce genre de mesure a permi d'identifier une classe définie en plusieurs milliers de lignes, avec plusieurs fonctions de plus de 2000 lignes (certaines de 10000 je crois), une complexité cyclotomatique de l'ordre de 100 dans pas mal de fonctions.
Il te faut un outil pour trouver ça ? La revue du code n'a rien dit ?
A priori, l'idée est de passer l'outil de mesure dès qu'on reçoit le code, afin d'avoir en quelques minutes une idée de l'étendue des dégâts. La revue de code ne vient qu'après.
-- ;-)
kanze
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "" :
[...]
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris), je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
Et si on ressent le besoin d'effectuer les tests, c'est que le code est mauvais ? C'est le même principe.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "noone@nowhere.com"
<noone@nowhere.com>:
[...]
Quant à memprof (détecteur de fuites mémoires si j'ai bien
compris), je serais presque tenté de dire que si on ressent le
besoin d'un tel outil, c'est que le code est mauvais.
Et si on ressent le besoin d'effectuer les tests, c'est que le
code est mauvais ? C'est le même principe.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quant à memprof (détecteur de fuites mémoires si j'ai bien compris), je serais presque tenté de dire que si on ressent le besoin d'un tel outil, c'est que le code est mauvais.
Et si on ressent le besoin d'effectuer les tests, c'est que le code est mauvais ? C'est le même principe.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Olivier Azeau wrote:
Loïc Joly wrote:
Olivier Azeau wrote:
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "" :
gprog
[gprof]
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier la lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Elle le peut. En général, même, il faut que le programme soit assez rapide. Il n'y a que la définition de « assez » qui varie. Mais gprof ne sert pas là -- gprof ne va pas me dire si l'utilisateur se frustre à cause des temps de réponse, par exemple, ni si mon serveur est capable de traiter 140 requêtes par séconde, comme c'est écrit dans le cahier de charge.
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère que qualité. Mais ce n'est pas ce que mesure un profiler. Un profiler a pour but de localiser les bottleneck, en faisant des mesures d'une granularité bien plus faible que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas un outil de *mesure* du critère de qualité "temps d'exécution", mais un outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
Je ne connais pas gprof mais les profilers que j'ai utilisés donnent aussi bien des mesures locales que des mesures plus globales (graphe d'appels + additions des temps...)
Mais c'est rarement ce qu'on veut non plus. Les exigences de temps se formulent en général en d'autres termes, comme « au moins n requêtes par séconde » ; souvent, elles ne se formulent même pas d'une façon quantitative -- où se situe le seuil de frustration d'un utilisateur. (Note bien que souvent, c'est mieux de répondre en moins d'une seconde la plupart du temps, et de dépasser les cinq sécondes une fois de temps à l'autre, que de répondre toujours dans deux sécondes. Quick sort est souvent préférable à heap sort.)
Dans un certain nombre de cas le profiler peut donner le temps perçu global *et* le bottleneck local.
Ceci étant dit, il est certain que dans le cas d'un code comportant pas mal d'I/O, le CPU consommé peut être insignifiant par rapport au temps perçu par l'utilisateur et donc le profiler ne sert pour ainsi dire à rien.
Typiquement, ce qui intéresse est l'ensemble. Donc, dans mes 140 requêtes par séconde, c'est égal où on passe le temps. (En l'occurance, une autre partie des cahiers de charges imposaient qu'on ait écrit l'état qui en résultait d'une manière synchrone sur disque avant d'envoyer la réponse à la requête. Avec une écriture synchrone qui dure environ 10 millisecondes. Il y avait donc bien un problème de performance, et gprof n'a aidé ni à l'isoler, ni même à le résoudre.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Olivier Azeau wrote:
Loïc Joly wrote:
Olivier Azeau wrote:
Fabien LE LEZ wrote:
On Mon, 24 Jan 2005 06:14:17 +0100, "noone@nowhere.com"
<noone@nowhere.com>:
gprog
[gprof]
A quoi sert-il exactement dans ce cas précis ? Il me
semble que gprof est un profiler, i.e. un programme qui
permet de savoir où optimiser le code (ce qui peut vouloir
dire sacrifier la lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un
bon critere de qualité ?
Elle le peut. En général, même, il faut que le programme soit
assez rapide. Il n'y a que la définition de « assez » qui varie.
Mais gprof ne sert pas là -- gprof ne va pas me dire si
l'utilisateur se frustre à cause des temps de réponse, par
exemple, ni si mon serveur est capable de traiter 140 requêtes
par séconde, comme c'est écrit dans le cahier de charge.
Je dirais ue la vitesse d'exécution du code vue par un
utilisateur au sens large peut être un bon critère que
qualité. Mais ce n'est pas ce que mesure un profiler. Un
profiler a pour but de localiser les bottleneck, en faisant
des mesures d'une granularité bien plus faible que le niveau
de qualité requis. Donc je dirais qu'un profiler n'est pas
un outil de *mesure* du critère de qualité "temps
d'exécution", mais un outil qui permet d'obtenir un temps
d'exécution conforme à celui requis.
Je ne connais pas gprof mais les profilers que j'ai utilisés
donnent aussi bien des mesures locales que des mesures plus
globales (graphe d'appels + additions des temps...)
Mais c'est rarement ce qu'on veut non plus. Les exigences de
temps se formulent en général en d'autres termes, comme « au
moins n requêtes par séconde » ; souvent, elles ne se formulent
même pas d'une façon quantitative -- où se situe le seuil de
frustration d'un utilisateur. (Note bien que souvent, c'est
mieux de répondre en moins d'une seconde la plupart du temps, et
de dépasser les cinq sécondes une fois de temps à l'autre, que
de répondre toujours dans deux sécondes. Quick sort est souvent
préférable à heap sort.)
Dans un certain nombre de cas le profiler peut donner le temps
perçu global *et* le bottleneck local.
Ceci étant dit, il est certain que dans le cas d'un code
comportant pas mal d'I/O, le CPU consommé peut être
insignifiant par rapport au temps perçu par l'utilisateur et
donc le profiler ne sert pour ainsi dire à rien.
Typiquement, ce qui intéresse est l'ensemble. Donc, dans mes 140
requêtes par séconde, c'est égal où on passe le temps. (En
l'occurance, une autre partie des cahiers de charges imposaient
qu'on ait écrit l'état qui en résultait d'une manière synchrone
sur disque avant d'envoyer la réponse à la requête. Avec une
écriture synchrone qui dure environ 10 millisecondes. Il y avait
donc bien un problème de performance, et gprof n'a aidé ni à
l'isoler, ni même à le résoudre.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
A quoi sert-il exactement dans ce cas précis ? Il me semble que gprof est un profiler, i.e. un programme qui permet de savoir où optimiser le code (ce qui peut vouloir dire sacrifier la lisibilité pour accélérer l'exécution).
Tu veux dire que la vitesse d'exécution ne peut pas etre un bon critere de qualité ?
Elle le peut. En général, même, il faut que le programme soit assez rapide. Il n'y a que la définition de « assez » qui varie. Mais gprof ne sert pas là -- gprof ne va pas me dire si l'utilisateur se frustre à cause des temps de réponse, par exemple, ni si mon serveur est capable de traiter 140 requêtes par séconde, comme c'est écrit dans le cahier de charge.
Je dirais ue la vitesse d'exécution du code vue par un utilisateur au sens large peut être un bon critère que qualité. Mais ce n'est pas ce que mesure un profiler. Un profiler a pour but de localiser les bottleneck, en faisant des mesures d'une granularité bien plus faible que le niveau de qualité requis. Donc je dirais qu'un profiler n'est pas un outil de *mesure* du critère de qualité "temps d'exécution", mais un outil qui permet d'obtenir un temps d'exécution conforme à celui requis.
Je ne connais pas gprof mais les profilers que j'ai utilisés donnent aussi bien des mesures locales que des mesures plus globales (graphe d'appels + additions des temps...)
Mais c'est rarement ce qu'on veut non plus. Les exigences de temps se formulent en général en d'autres termes, comme « au moins n requêtes par séconde » ; souvent, elles ne se formulent même pas d'une façon quantitative -- où se situe le seuil de frustration d'un utilisateur. (Note bien que souvent, c'est mieux de répondre en moins d'une seconde la plupart du temps, et de dépasser les cinq sécondes une fois de temps à l'autre, que de répondre toujours dans deux sécondes. Quick sort est souvent préférable à heap sort.)
Dans un certain nombre de cas le profiler peut donner le temps perçu global *et* le bottleneck local.
Ceci étant dit, il est certain que dans le cas d'un code comportant pas mal d'I/O, le CPU consommé peut être insignifiant par rapport au temps perçu par l'utilisateur et donc le profiler ne sert pour ainsi dire à rien.
Typiquement, ce qui intéresse est l'ensemble. Donc, dans mes 140 requêtes par séconde, c'est égal où on passe le temps. (En l'occurance, une autre partie des cahiers de charges imposaient qu'on ait écrit l'état qui en résultait d'une manière synchrone sur disque avant d'envoyer la réponse à la requête. Avec une écriture synchrone qui dure environ 10 millisecondes. Il y avait donc bien un problème de performance, et gprof n'a aidé ni à l'isoler, ni même à le résoudre.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
