Critères de tri

Fondamentalement, perf report produit un histogramme : on groupe les échantillons d’activité système observée selon certains critères, pour l’activité CPU c’est par défaut la commande (comm), le binaire (dso) et la fonction (sym) où une activité a été observée. Puis on indique dans quels cas, selon ces critères, on observe le plus d’activité système.

Il est possible, si on le souhaite, de modifier ces critères de tri. Par exemple, on peut demander un histogramme à gros grain, qui ne trie que par commande et par binaire…

perf report --sort comm,dso

…et on en déduit qu’au plus 39% du temps CPU écoulé est attribuable au code directement écrit dans TPhysics.cpp et TPhysics.hpp, le reste étant passé dans du code de la bibliothèque standard. Autrement dit, si l’on ne modifiait que le code de la simulation sans affecter le nombre et le type d’appels à la bibliothèque standard, le programme irait au mieux 39% plus vite.

(“Au mieux” parce qu’une partie du code de la bibliothèque standard se retrouve inlinée dans TPhysics.bin et ne serait pas affectée par ces manipulations, et aussi parce qu’il faudrait pour atteindre ce gain maximal ramener le temps d’exécution du code métier à zéro.)

A l’inverse, on peut demander un histogramme à grain plus fin, par exemple en demandant pour quelles lignes de code source la plus forte activité système est observée :

perf report --sort comm,dso,sym,srcline

Ce ne sont que des exemples, bien d’autres critères sont disponibles, notamment le PID (utile pour discriminer le processus source dans des environnements multi-processus) et le TID (pour discriminer le thread source dans des programmes multi-thread). Consultez la partie sur l’option --sort de perf help report pour en savoir plus.

Exercice : Utiliser perf report pour afficher un histogramme où les échantillons sont groupés par binaire et par ligne de code source uniquement.

Vous observerez quelques erreurs de BFD (la bibliothèque issue de binutils utilisée par perf pour manipuler des binaires ELF), qui sont liées au fait que l’interprétation d’informations de déboguage n’est malheureusement pas une science exacte, surtout au niveau du code noyau.

Dans le cas présent, vous pouvez éviter ces erreurs en ne mesurant que l’activité applicative, sans regarder celle du noyau. Il suffit pour cela de relancer la commande perf record en y ajoutant l’option -e cycles:uP (relisez la partie sur perf list si vous avez oublié ce que ce :uP signifie).