Profilage (programmation informatique)

Les profileurs plats calculent les temps d'appel moyens à partir des appels, sans ventiler les temps d'appel en fonction de l'appelé ou du contexte.

Les profileurs de graphes d'appels affichent les temps d'appel et les fréquences des fonctions, ainsi que les chaînes d'appels impliquées en fonction de l'appelé. Dans certains outils, le contexte complet n'est pas préservé .

Les profileurs sensibles aux entrées ajoutent une dimension supplémentaire aux profileurs plats ou basés sur des graphes d'appels en reliant les mesures de performance aux caractéristiques des charges de travail d'entrée, telles que la taille ou les valeurs des données. Ils génèrent des graphiques qui caractérisent l'évolution des performances d'une application en fonction de ses entrées.

Des profileurs événementiels sont disponibles pour les langages de programmation suivants :

• Java : l' API JVMTI (JVM Tools Interface), anciennement JVMPI (JVM Profiling Interface), fournit des points d'entrée aux profileurs, pour intercepter des événements tels que les appels, le chargement, le déchargement et l'entrée/sortie de classes et de threads.
• .NET : Il est possible de connecter un agent de profilage au CLR en tant que serveur COM via l’API de profilage . À l’instar de Java, l’environnement d’exécution fournit ensuite diverses fonctions de rappel à l’agent, permettant de détecter des événements tels que l’exécution, l’entrée et la sortie de méthodes JIT , la création d’objets, etc. Cette fonctionnalité est particulièrement puissante car l’agent de profilage peut réécrire le bytecode de l’application cible de manière arbitraire.
• Python : Le profilage Python inclut le module profile, hotshot (qui est basé sur le graphe d'appels) et l'utilisation de la fonction 'sys.setprofile' pour intercepter des événements tels que c_{call,return,exception}, python_{call,turn,exception}.
• Ruby : Ruby utilise également une interface similaire à celle de Python pour le profilage. On y trouve Flat-profiler (dans le fichier profile.rb), un module et ruby-prof (une extension C).

Ces profileurs fonctionnent par échantillonnage . Un profileur par échantillonnage analyse la pile d'appels du programme cible à intervalles réguliers en utilisant les interruptions du système d'exploitation . Les profils d'échantillonnage sont généralement moins précis et spécifiques numériquement, ne fournissant qu'une approximation statistique, mais permettent au programme cible de s'exécuter à une vitesse proche de sa vitesse maximale. « L'erreur réelle est généralement supérieure à une période d'échantillonnage. En fait, si une valeur est n fois la période d'échantillonnage, l'erreur attendue est égale à la racine carrée de n périodes d'échantillonnage. »

En pratique, les profileurs par échantillonnage offrent souvent une image plus précise de l'exécution du programme cible que d'autres approches, car ils sont moins intrusifs et ont donc moins d'effets secondaires (notamment sur les caches mémoire ou les pipelines de décodage d'instructions). De plus, leur faible surcharge permet de détecter des problèmes qui resteraient autrement invisibles. Ils sont également relativement insensibles à la surestimation du coût des petites routines fréquemment appelées ou des boucles « serrées ». Ils peuvent indiquer le temps relatif passé en mode utilisateur par rapport au temps passé en mode noyau interruptible, comme lors du traitement des appels système .

Malheureusement, l'exécution de code noyau pour gérer les interruptions entraîne une légère perte de cycles CPU pour le programme cible, détourne l'utilisation du cache et ne permet pas de distinguer les différentes tâches exécutées par le code noyau non interruptible (activité de l'ordre de la microseconde) de celles exécutées par le code utilisateur. Le matériel dédié offre de meilleures performances : les interfaces JTAG des processeurs ARM Cortex-M3 et de certains processeurs MIPS récents disposent d'un registre PCSAMPLE qui échantillonne le compteur de programme de manière totalement indétectable, permettant ainsi la collecte non intrusive d'un profil d'activité plat.

utilisés pour le code Java/managé, on trouve de SmartBear Software et CLR Profiler de Microsoft . Ces profileurs prennent également en charge le profilage du code natif, ainsi que Shark d' Apple Inc. OSX) , OProfile (Linux) , Intel VTune et Parallel Amplifier (qui fait partie d' Intel Parallel Studio ), et Oracle Performance Analyzer , entre autres.

Cette technique consiste à ajouter des instructions au programme cible afin de collecter les informations nécessaires. Il est important de noter que l'instrumentation d'un programme peut modifier ses performances et, dans certains cas, engendrer des résultats inexacts et/ou des bogues de Heisenberg . L'effet dépendra des informations collectées, du niveau de détail temporel rapporté et de l'utilisation ou non du profilage par blocs de base en complément de l'instrumentation. Par exemple, l'ajout de code pour compter chaque appel de procédure/routine aura probablement moins d'impact que le comptage du nombre d'exécutions de chaque instruction. Certains ordinateurs disposent d'un matériel dédié à la collecte d'informations ; dans ce cas, l'impact sur le programme est minime.

L'instrumentation est essentielle pour déterminer le niveau de contrôle et la résolution temporelle disponibles pour les profileurs.

• Manuel : Effectué par le programmeur, par exemple en ajoutant des instructions pour calculer explicitement les temps d'exécution, compter simplement les événements ou les appels aux API de mesure telles que la norme Application Response Measurement .
• Niveau source automatique : instrumentation ajoutée au code source par un outil automatique selon une politique d’instrumentation.
• Langage intermédiaire : instrumentation ajoutée à l'assembleur ou aux bytecodes décompilés permettant la prise en charge de plusieurs langages sources de niveau supérieur et évitant les problèmes de réécriture de décalage binaire (non symbolique).
• Compilateur assisté
• Traduction binaire : L'outil ajoute des instruments à un exécutable compilé .
• Instrumentation à l'exécution : Le code est instrumenté juste avant son exécution. L'exécution du programme est entièrement supervisée et contrôlée par l'outil.
• Injection dynamique : plus légère que l’instrumentation dynamique. Le code est modifié à l’exécution pour effectuer des sauts vers des fonctions auxiliaires.

• Les options de débogage de l'interpréteur permettent de collecter des indicateurs de performance à chaque exécution d'une instruction cible. Les interpréteurs de bytecode , de table de contrôle ou JIT sont trois exemples d'interpréteurs qui contrôlent généralement l'exécution du code cible de manière exhaustive, offrant ainsi des possibilités de collecte de données extrêmement complètes.

• Hyperviseur : Les données sont collectées en exécutant le programme (généralement) non modifié sous un hyperviseur . Exemple : SIMMON
• Simulateur et hyperviseur : Données collectées de manière interactive et sélective en exécutant le programme non modifié sous un simulateur de jeu d'instructions .