[glob2-devel] Optimisation, profiler et verite

[Stephane Magnenat]

Bonjour,

Je suis tjr trouble par tous les resultats inconsistants que l'on a eu avec le 
profiler (les 72% dans drawFilledRect par exemple, alors que le jeu est bien 
plus lent et que rien a change dans l'affichage). J'ai dit que l'optimisation 
trashait les resultats du profiler. 
C'est en tout cas ce que j'avais constate a l'epoque (il y a 2 ans quand je 
m'etais serieusement interesse a la question) (et meme trouve dans une 
doc mais je ne retrouve plus). Peut-etre que gcc 3.X gere tout ca 
correctement. Voici ce que j'ai pu trouve sur gprof (c'est bien gprof que tu 
as utilise Luc ?).

De la doc de gprof :
"If you use gcc 2.95.x or 3.0 to compile your binaries, you may need to add 
the -fprofile-arcs to the compile command line in order for the call graphs 
to be properly stored in gmon.out. "

Il y a des problemes avec le multithreading et la libc :
"glibc does not support profiling multithreaded programs"
http://www.kegel.com/gprof.html
http://slashdot.org/articles/02/07/05/1457231.shtml

Selon RedHat, gprof ne sert a rien :
http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8&selm=linux.kernel.1016237961.5612.51.camel%40myware.mynet

Il semblerait qu'il y ait une alternative (lire les limitations de gprof) :
http://www710.univ-lyon1.fr/~yperret/fnccheck/Welcome.html

Voila. Faudra que je teste FunctionCheck. A priori, la, j'aurai plus tendance 
a faire confiance au profiler de OS X.
A noter que glob2 passe un certain temps dans BlitRGBA et drawFilledRect (mais 
pas la majorite). Ces fonctions seront grandement optimisees quand j'aurai 
fini le backend GL. Ce qui est rigolo, c'est que l'affichage des choses en 
palette ou rotation ne semble pas prendre bcp de temps.

En esperant que ca clot une flame war dont je ne voulais pas mais dont j'ai 
probablement ete l'instigateur par imprudence.

Bonne journee,

Steph