Chapitre 3. Concepts de base

Ce chapitre explique quelques concepts de KCachegrind, et introduit les termes utilisés dans l'interface.

Le modèle de données pour les données de profilage

Entités de coût

Les compteurs de coût des types d'évènement (comme les échecs du cache L2) sont attribués aux entités de coût, qui sont des éléments en relation avec le code source ou des structures de données d'un programme donné. Les entités de coût ne sont pas seulement un code simple ou des positions de données, mais aussi des tuples de position. Par exemple, un appel a une source et une cible, ou bien une adresse de données peut avoir un type de données et une position dans le code où son allocation s'est effectuée.

Les entités de coût connues de KCachegrind sont données ci-dessous. Les positions simples :

Instruction

Une instruction assembleur à l'adresse spécifiée.

Ligne dans le source d'une fonction

. Toutes les instructions que le compilateur (par l'intermédiaire des informations de débogage) associe à une ligne donnée spécifiée par le nom du fichier source et le numéro de la ligne, et qui sont exécutées dans le contexte de quelques fonctions. Le dernier est nécessaire parce qu'une ligne source à l'intérieur d'une fonction inline peut apparaître dans le contexte de fonctions multiples. Les instructions sans association avec une ligne du code source courant sont associées à la ligne numéro 0 du fichier « ??? ».???.

Function

Fonction. Toutes les lignes d'une fonction donnée constituent la fonction elle-même. Une fonction est spécifiée, s'ils sont disponibles, par son nom et sa position dans quelques objets binaires. La dernière est nécessaire parce que les objets binaires d'un seul programme peut avoir des fonctions avec le même nom (on peut y accéder par exemple avec dlopen ou  dlsym; l'éditeur de lien dynamique résout les fonctions dans un ordre de recherche donné dans les objets binaires utilisés). Si un outil de profilage ne peut détecter le nom du symbole d'une fonction, par exemple parce que l'information de débogage n'est pas disponible, soit l'adresse de la première instruction exécutée est utilisée, soit ???

Objet binaire.

Toutes les fonctions dont le code se situe à l'intérieur d'un objet binaire, ou bien l'exécutable principal (NdT : « main »), ou encore une librairie partagée.

Fichier source.

Toutes les fonctions dont la première instruction est associée à une ligne d'un fichier source donné.

Classe.

Les noms des symboles des fonctions sont généralement ordonnés hiérarchiquement dans des espaces de nommage, par exemple les espaces de nommage C++, ou les classes des langages orientés objet. Ainsi une classe peut contenir des fonctions d'une classe ou de classes embarquées.

Partie d'un profilage.

Quelques sections de temps d'une exécution de profilage, avec un identifiant de thread donné, un identifiant de processus, et la ligne de commande exécutée.

Comme on peut le voir depuis la liste, un ensemble d'entités de coût définit souvent une autre entité de coût. Ainsi il y a une hiérarchie d'imbrication des entités de coût qui semble évidente par rapport à la description faite au-dessus.

Tuples des positions :

  • Appel d'une adresse d'instruction vers une fonction cible.

  • Appel d'une ligne du source vers une fonction cible.

  • Appel d'une fonction du source vers une fonction cible.

  • Saut (in)conditionnel d'une source vers une instruction cible.

  • Saut (in)conditionnel d'une source vers une ligne cible.

Les sauts entre les fonctions ne sont pas autorisés, car cela est absurde dans un arbre d'appels. Ainsi, les constructions telles la gestion des exceptions et les sauts longs en C doivent être traduits pour se mettre dans la pile d'appels comme demandé.

Types d'évènement

Des types d'évènements arbitraires peuvent être spécifiés dans les données de profilage en leur donnant un nom. Leur coût relié à une entité de coût est un entier sur 64 bits.

Les types d'évènement dont les coûts sont spécifiés dans le fichier de données de profilage sont appelés évènement réels. En plus, on peut spécifier des formules pour les types d'évènement calculés à partir d'évènement réels, que l'on appelle évènements hérités.