Échantillonnage

Avant d’étudier perf annotate, ou les autres outils basés sur perf record, il faut avoir bien compris la notion théorique de profilage par échantillonnage.

Lorsqu’on étudie la performance d’un programme, il est important de le faire de façon aussi peu intrusive que possible. Sinon, on risque de mesurer les caractéristiques de performances de son outil de mesure plutôt que celles du programme qui nous intéresse.

De ce point de vue, il n’est pas souhaitable de mesurer la façon dont un programme utilise ses cycles CPU en analysant la position du pointeur d’instruction (= le point du programme où on se trouve) à chaque cycle CPU. En effet, analyser la position du pointeur d’instruction (ou même juste l’écrire quelque part) demande plusieurs cycles CPU, pendant lesquels le programme ne pourrait pas avancer sous peine de devancer le profileur. Donc cela conduirait à ralentir démesurément l’exécution du programme, en nous éloignant d’autant d’une exécution réaliste. Ainsi, un programme limité par les entrées-sorties “dans la vraie vie” pourrait apparaître limité par la vitesse d’exécution de code dans les mesures.

De même, quand on s’intéresse à l’utilisation du cache CPU, il ne serait pas souhaitable d’enregistrer des informations à propos de chaque défaut de cache L1, car cela arrive aussi bien trop souvent.

A la place, tous les profileurs modernes utilisent une approche statistique appelée échantillonnage, où l’on n’enregistre qu’un sous-ensemble des événements qui nous intéressent (N événements par seconde, ou bien 1 événement tous les N événements), appelés échantillons.

L’idée de cette approche est que si notre jeu d’échantillons est représentatif et de taille suffisante, nous pouvons en conclure à peu près les mêmes choses que nous aurions conclues si nous avions eu le loisir d’enregistrer et analyser la totalité des événements. Par exemple, si nous avons mesuré un grand nombre d’échantillons et 20% d’entre eux tombent dans une certaine partie du code, alors nous pouvons supposer que si nous avions pu mesurer la totalité des événements étudiés, environ 20% se seraient produits dans cette même partie du code.

Une originalité de perf par rapport à d’autres profileurs fonctionnant par échantillonnage est que ce profileur n’est pas seulement capable de mesurer quelles sont les parties du code où l’on passe beaucoup de cycles CPU, mais plus généralement quelles sont les parties du code qui sont corrélées à toutes sortes d’événements système : défauts de cache, écritures disque, etc.