Comment profiler mon application C ++ sur Linux

Je peux recommander l’outil callgrind de valgrind en conjonction avec KCacheGrind pour la visualisation. KCacheGrind vous permet de voir facilement où se trouvent les zones sensibles.

Note: Cela fait trop longtemps que je ne l’ai pas utilisé, alors je ne suis pas sûr que vous puissiez obtenir un temps d’attente d’E / S. Peut-être qu’en conjonction avec iostat ou pidstat vous pourrez voir où tout le temps a été passé.

Découvrez oprofile . Pour plus de diagnostics au niveau du système, essayez systemtap .

Vous pourriez vouloir vérifier Zoom , qui est beaucoup plus poli et complet que oprofile et al . Cela coûte de l’argent (199 $), mais vous pouvez obtenir une licence d’évaluation gratuite de 30 jours.

LTTng est un bon outil à utiliser pour le profilage complet du système.

Si votre application fonctionne simplement “à plat” (c’est-à-dire qu’elle utilise un processeur ou attend des E / S) jusqu’à ce qu’elle se /usr/bin/time myapp , qui produit une sortie légèrement différente du shell intégré).

Cela vous donnera quelque chose comme:

 real 0m1.412s user 0m1.288s sys 0m0.056s 

Dans ce cas, le temps utilisateur + sys (kernel) représente presque tout le temps réel et il n’ya que 0,068s non comptabilisés (probablement le temps passé à charger l’application et ses librairies).

Cependant, si vous deviez voir:

 real 0m5.732s user 0m1.144s sys 0m0.078s 

alors votre application a dépensé 4.51s ne consommant pas de CPU et probablement bloquée sur IO. Quelle est l’information que je pense que vous recherchez.

Cependant, où cette technique d’parsing simple se décompose est la suivante:

• Des applications qui attendent une timer / horloge ou un autre stimulus externe (par exemple, des applications GUI pilotées par des événements). Il ne peut pas distinguer le temps d’attente sur l’horloge et le temps d’attente sur le disque / réseau.
• Applications multithread, qui nécessitent un peu plus de reflection pour interpréter les chiffres.

callgrind est un très bon outil mais j’ai trouvé OProfile plus “complet”. En outre, il est le seul à vous permettre de spécifier les sources des modules et / ou du kernel afin de mieux comprendre vos goulots d’étranglement. La sortie est supposée être capable d’interfacer avec KCacheGrind mais j’ai eu du mal avec ça, j’ai donc utilisé Gprof2Dot à la place. Vous pouvez exporter votre callgraph vers un .png.

Modifier:

OProfile se penche sur l’ensemble du système afin que le processus ne soit que:

[configurer oprofile]

 opcontrol --init opcontorl --vmlinux=/path/to/vmlinux (or --no-vmlinux) opcontrol --start 

[exécutez votre application ici]

 opcontrol --stop (or opcontrol --shutdown [man for difference] 

puis pour commencer à regarder les résultats regarder la page de manuel sur opreport

Les outils de laquais et / ou de helgrind de valgrind devraient vous permettre de le faire.

google-perf-tools – une alternative beaucoup plus rapide à callgrind (et peut générer des résultats au même format que callgrind, vous pouvez donc utiliser KCacheGrind).

Voir ce post.

Et ce post.

Fondamentalement, entre le démarrage du programme et sa fin, il dispose d’une stack d’appels. Pendant les E / S, la stack se termine par un appel système. Pendant le calcul, il se termine par une instruction typique.

De toute façon, si vous pouvez échantillonner la stack à des heures aléatoires, vous pouvez voir exactement pourquoi elle passe ce temps.

Le seul point qui rest est que des milliers d’échantillons peuvent donner un sentiment de confiance, mais ils ne vous diront pas beaucoup plus que 10 ou 20 échantillons.