Profiling/fr

│ English (en) │ français (fr) │ русский (ru) │

Profiling est une technique d'analyse des performances qui peuvent être utilisées pour trouver les goulots d'étranglement dans votre application. En particulier, elle englobe la mesure de la fréquence et de la durée des appels de fonction.

Profilage et optimisation

Le profilage peut aider à identifier les différentes parties 'critiques' de votre code, dont l'optimisation pourrait sérieusement améliorer la performance de votre programme. Il vaut mieux le faire au moment ou vous vous préparez à faire une réalisation(release) et que vous avez une fonctionnalité qui ralenti fortement votre code. C'est une perte de temps et de ressources d'optimiser quelque chose qui va être jeté les jours suivant pendant une quelconque restructuration de code.

Faites attention à ne pas sur-optimiser votre programme. Cela vaut rarement la peine de passer des jours à la seule obtention d'un gain d'exécution de 2%. On peut généralement éliminer 30% du temps d'exécution en juste une demi heure de codage avec quelques optimisations qui seront utiles.

Bien sûr, l'optimisation du code qui est très souvent réutilisé vaut un peu plus d'efforts pour gagner en performance.

Prise en charge du profileur par FreePascal

FreePascal a une prise en charge intégrée pour produire des exécutables appropriés (au moins) pour deux profileurs:

• gprof, le profileur Gnu: permis avec l'option -pg.
• Valgrind, en utilisant le plug-in Callgrind: permis avec l'option -gv.

Malheureusement, la prise en charge du profileur pourrait ne pas être disponible (a moins de: travailler directement de manière séparée) pour toutes les plateformes. gprof ne fonctionne plus avec linux depuis fpc 2.2.0. Valgrind devrait fonctionner avec Linux (et systèmes apparentés). Pour Windows des étapes supplémentaires pourraient être nécessaires pour la prise en charge de gprof fonctionne. Valgrind est tout simplement disponible uniquement pour Linux et quelques autres systèmes UNIX.

Utilisation de Valgrind/Callgrind

Valgrind était à l'origine seulement un débogueur de mémoire, mais maintenant il prend aussi en charge par exemple le profilage à l'aide du plug-in Callgrind( qui a remplacé le plugin calltree). Pour installer Valgrind avec Callgrind sur Debian, exécutez par exemple

 aptitude install valgrind valgrind-callgrind

Pour profiler votre programme, vous devez suivre trois étapes

• Compilez votre programme avec l'option -gv .
• Exécutez votre programme en utilisant valgrind
• Analyser la sortie obtenue avec valgrind_annotate ou avec l'outil avec interface graphique KCacheGrind

Compilez votre programme avec

 fpc -gv myprogram.pas

Exécutez Valgrind en utilisant par exemple

 valgrind --tool=callgrind ./myprogram --options --to --my --program

Vous pouvez également profiler uniquement des parties spécifiques de votre programme.  Par exemple vous pouvez démarrer le programme avec

 valgrind --instr-atstart=off ./myprogram --options --to --my --program

Au moment ou vous voulez que le profilage réel démarre, exécutez

 valgrind_control -i on

Pour arrêter le profilage,  exécutez la même commande avec off  au lieu de on.  Pour obtenir uniquement des informations de profilage quand vous êtes dans une fonction particulière, vous pouvez transmettre l'option --toggle-collect=funcNamePrefix à valgrind.  Reportez-vous à la documentation de Valgrind pour plus de détails. 

Callgrind a créé un fichier de traçage avec un nom typique du genre callgrind.out.12345. Pour obtenir un rapport statistique lisible, exécutez par exemple

 callgrind_annotate callgrind.out.12345

Bien sûr, vous pouvez également faire une expérimentation avec les autres outils plug-ins  qui sont fournies avec Valgrind. Cachegrind,  par exemple, fait le profilage de l'utilisation du cache. d'autres plug-ins  peuvent être utilisés pour profiler ou déboguer l'allocation de mémoire ou détecter les conditions de transfert de données  data race conditions.

Using KCacheGrind

Though the output of callgrind_annotate can definitely shed some light on the performance characteristics of your program, the GUI tool KCacheGrind can give you even more interesting information, presented in different forms: caller/callee lists, caller/callee maps ans call graphs. To install it on Debian, run

 aptitude install kcachegrind graphviz

(The graphviz package is required if you want KCacheGrind to generate call graphs.)

Example of KCacheGrind showing profiling information for Lazarus (Click to enlarge)

Run KCachegrind with a simple call to kcachegrind. You can now open a trace file using the GUI and all should eb self-explanatory.

On the left, you will see a 'flat profile', which list for each function (in the top 100)

• Incl: amount of time spent in the function, including callees (functions called by the function).
• Self: amount of time spent within the function itself, excluding callees.
• Called: the number of the times the function has been called.

Note: if you click on one of the column headers to sort the list, you might need to do a reload (F5) to ensure that the top 100 with respect to that column will be shown. Another hint: in the configuration options, you can make the list longer than only the top 100.

On the right, you'll see a number of tabs, allowing you to see lists and maps of callers and callees, as well as a caller graph, which is very useful to see in a glance who calls whom the most.

Memory Profiling

Heaptrc, LineInfo

To spot memory leaks, simply compile with -gh. This will compile as if you added the heaptrc unit as first unit to the uses section of your program. Heaptrc links into the memory manager of fpc and checks various things. Together with the -gl option (adding the lineinfo unit) it will give you useful information and backtraces, where a memory block was allocated. It supports some options that can be controlled via environment option HEAPTRC containing keywords:

• keepreleased: Any freed memory, is kept and checked if overwritten.
• disabled: disable tracing. This is useful for program compiled with heaptrc and should work normally.
• nohalt: normally heaptrc stops on the first error it finds. Add this keyword if the program should continue (as it would normally do without heaptrc).
• haltonnotreleased: Normally heaptrc prints for every not freed block a backtrace, which can take a long time. Add this keyword to stop after first reported mem leak.
• log=<filename>: Instead of writing to stdout, you can give a log filename.

Note: heaptrc will conflict with cmem if you have to debug external libraries. Valgrind should be used in this case.

Valgrind Memcheck

There are mem leaks which heaptrc does not find. The valgrind program has a tool called memcheck, which does a lot more bookkeeping than heaptrc and finds some more bugs. The drawback is that valgrind is snail slow, so do this only if heaptrc could not help you. Here is an example:

 valgrind --tool=memcheck --leak-check=summary --log-file=log.txt ./project1

The log.txt will almost always find something, because it tries to check the used external libraries too and some common libraries are badly coded.

To get even more information run with

 valgrind --tool=memcheck --leak-check=full --log-file=log.txt --show-reachable=yes --num-callers=128 ./project1