Prérequis

Pour corréler des mesures à des emplacements dans le code source de l’application, perf report a besoin de comprendre la façon dont l’application s’exécute. En simplifiant un peu…

• L’analyse sera relativement simple pour les programmes compilés avant l’exécution, le cas habituel en C/++, Fortran et Rust. Elle est basée sur les métadonnées des binaires ELF, communes à tous ces langages. Il faudra juste penser à compiler avec des informations de déboguage (flag -g de GCC et clang) pour des résultats optimaux.
• Quand les programmes sont compilés à la volée, le cas habituel en Java, JavaScript et Julia, il faudra que perf puisse communiquer avec le compilateur pour obtenir les informatiques requises. Beaucoup de compilateurs populaires le permettent, mais souvent au prix d’une reconfiguration/recompilation avec des options spéciales qui ne sont pas activées dans les paquets binaires de la plupart des distributions Linux…
• Et quand les programmes sont interprétés, le cas habituel en Python, Ruby et bash, on ne pourra souvent se rapporter qu’au code source de l’implémentation de l’interpréteur et des bibliothèques externes compilées statiquement, ce qui sera rarement satisfaisant.

Notez la répétition de l’expression “cas habituel” ci-dessus. Le modèle d’exécution n’est pas une propriété d’un langage, mais d’une implémentation de ce langage. On peut compiler du C++ à la volée comme le fait l’interpréteur cling de ROOT, tout comme on peut compiler du Python statiquement (Cython, Pythran) ou à la volée (Numba, PyPy). Mais la plupart des langages de programmation ont un type d’implémentation privilégié.

Par ailleurs, nous verrons plus loin que comme perf annotate et perf trace, perf report pourra effectuer une analyse plus fine si il dispose des informations de déboguage de l’application et de tous les binaires externes qu’elle utilise : noyau du système d’exploitation, bibliothèques…