gprof

Bonjour, je voudrai profiler un programme que j'ai fait.
J'utilise gprof, mais cela ne me donne pas des résultats convaiquants .
Je m'explique, prenons le programme suivant :

#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

void fct1(const int s)
{
sleep(s);
}

void fct2(const int t)
{
int i;

for(i=0; i<t; i++);
}

int main(int argc, char * argv[])
{
fct1(10);
fct2(100000);
return EXIT_SUCCESS;
}

je le compile comme ca : gcc -static -pg -g gprof.c

Quand j'utilise gprof : gprof a.out gmon.out
Voilà la résultat :

Flat profile:

Each sample counts as 0.01 seconds.
no time accumulated

% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
0.00 0.00 0.00 1 0.00 0.00 fct1
0.00 0.00 0.00 1 0.00 0.00 fct2
0.00 0.00 0.00 1 0.00 0.00 main

...

Ce n'est pas du tout ce à quoi je m'attendais. Comment chaque fct peu t
prendre moins de 0.01 seconds, alors que je fais un sleep(10) ????

Deuxième problème, mon application est en réalité multi-threadé ! Il
paraît que sous linux (2.4.18), gprof ne peut profiler que le thread
principal, ce qui en général n'est pas très interessant. Une tech nique
existe et est décrite ici :
http://sam.zoy.org/writings/programming/gprof.html. Je voulais savoir s i
cette technique était bien fiable et si les résultats obtenus ét aient
réellement utilisables.

Merci d'avance

ben64

Ce n'est pas du tout ce à quoi je m'attendais. Comment chaque fct peut
prendre moins de 0.01 seconds, alors que je fais un sleep(10) ????

Deuxième problème, mon application est en réalité multi-threadé ! Il
paraît que sous linux (2.4.18), gprof ne peut profiler que le thread
principal, ce qui en général n'est pas très interessant.

ben64 wrote:

Ce n'est pas du tout ce à quoi je m'attendais. Comment chaque fct peut
prendre moins de 0.01 seconds, alors que je fais un sleep(10) ????

Parce que gprof mesure le temps de travail, et quand un code
dort, il ne travaille pas beaucoup.
Si tu veux faire un code qui calcule pendant 10 secondes, fait
plutôt quelque chose du genre
void foo(){
long l=0;
time_t start, current;
for(time(&start); time(&current), current-start<&0; ){
/* Un peu de code qui travaille, genre
l+= (l<1000)?(l+3):(l/2-1);
}
}
/* code non testé et crade par pur plaisir */

Deuxième problème, mon application est en réalité multi-threadé ! Il
paraît que sous linux (2.4.18), gprof ne peut profiler que le thread
principal, ce qui en général n'est pas très interessant.

Parfois, pour certains objectifs, il faut se tourner
vers des outils payants. Je me souviens que l'environnement
de développement de Sun faisait ça à merveille.

Marc Boyer

OK merci pour la reponse. Alors du coup j'ai une autre question. Je suis
bien content de savoir qu'une fonction me prend 40% de temps processeur.
Cependant si elle me prend 0.001% de temps global, je ne vais pas
m'attarder dessus. Car supposons que j'arrive à améliorer ses
performances, le temps de réponse pour l'utilisateur sera complètement
négligeable et il ne verra pas la différence. Alors comment trouver un
moyen fiable pour savoir quel bout de code prend vraiment du temps ?
Cela me permettra de focaliser mon travail sur ce bout de code et
d'ainsi améliorer les performances globales (temps de réponse pour
l'utilisateur).

Ben, hormis les cas de "sleep" explicite, c'est généralement
l'utilisation des ressources qui prends du temps. Non ?

Ben, hormis les cas de "sleep" explicite, c'est généralement
l'utilisation des ressources qui prends du temps. Non ?

PS: Quand on répond à un message, on réponde "après", en ayant pris soin
de ne conserver du message d'origine que ce qui est pertinent pour la suite
de la discussion.

"b" == ben64 <b.camredonnews@semlor.net> writes:

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

Ben, hormis les cas de "sleep" explicite, c'est généralement
l'utilisation des ressources qui prends du temps. Non ?

Les attentes d'IO. Et on peut arriver a gagner pas mal en les
reorganisants. J'ai vu un ordre de grandeur par rapport a du code qui
se pretentait optimise.

Toutes les librairies, que vous utilisez, ne sont pas compilées avec
l'option -pg, c'est pour cela que gprof vous donne des résultats qui vous
semblent étranges. Certains linux proposent (la debian), en option, ces
librairies compilées avec le bon switch (libc6-prof par exemple)