web-dev-qa-db-fra.com

Profilage du processus de compilation C ++

J'ai tendance à écrire des bibliothèques C++ basées sur des modèles plutôt volumineuses et mes utilisateurs se plaignent généralement des temps de compilation. Après avoir réfléchi à la question, il m'est venu à l'esprit que Je n'ai aucune idée où le temps va . Existe-t-il un moyen simple de profiler le processus de compilation C++ avec des compilateurs courants, tels que g ++, icc et xlC? Par exemple, est-il possible d'avoir une idée du temps passé en chacune des phases de la compilation C++ ?

c++compilationprofiling
75
Jack Poulson

Pour [~ # ~] gcc [~ # ~] il y a options de débogage pour trouver how much time is spent within each of the phases of C++ compilation?

- Q Fait en sorte que le compilateur imprime chaque nom de fonction au fur et à mesure qu'il est compilé, et imprime des statistiques sur chaque passage à la fin.

- ftime-report Fait en sorte que le compilateur affiche des statistiques sur le temps consommé par chaque passage à la fin.

Les passes sont décrites dans GCCINT 9: Passes et fichiers du compilateur .

Vous pouvez publier la sortie de la compilation g ++ d'un fichier source unique avec -v -ftime-report ici pour en discuter . Il pourrait y avoir de l'aide sur le GCC liste de diffusion .

Pour les compilateurs autres que GCC (ou GCC plus ancien que .3.6 ) voir les autres options de ce fil.

57
osgx

Il y a n outil du projet Boost, qui pourrait être utile pour à peu près n'importe quel compilateur et système de construction.

L'outil nécessite l'instrumentation du code source avec les appels de macros TEMPLATE_PROFILE_ENTER() et TEMPLATE_PROFILE_EXIT(). Ces macros génèrent ensuite des diagnostics spécifiques (avertissements) au moment de la compilation, qui sont chronométrés et collectés avec des piles d'appels d'instanciation (qui permettent par conséquent la construction et visualisation callgraphs) par un script. Pas mal, l'OMI.

Je ne l'ai pas encore utilisé.

14
ulidtko

Je ne l'ai pas encore essayé, mais templight semble TRÈS prometteur: https://github.com/mikael-s-persson/templight

7
Paul Brannan

Vous pouvez les séparer dans une certaine mesure (je suppose que make)

  • ajouter une règle de génération qui prétrait uniquement les fichiers (en utilisant le -E switch) et un .PHONY cible qui dépend des fichiers de sortie du préprocesseur tout comme la cible binaire normale dépend de .o des dossiers. Mesurer le temps qu'il faut pour construire cet objectif
  • ajouter un 'PHONY cible qui dépend de tous les .o fichiers mais ne les lie pas. Mesurer le temps qu'il faut pour construire cette cible (à partir de la propreté)
  • mesurer le temps qu'il faut pour faire une construction propre du binaire habituel

Vous savez maintenant combien de temps il faut pour pré-traiter, compiler et lier. Vous pouvez également comparer optimisé et non optimisé (-O0) versions des deuxième et troisième cibles, pour voir combien de temps est passé dans l'optimiseur.

4
Useless

Vous pourriez être en mesure d'obtenir une certaine traction avec une variante sur strace -e trace=process -f -r -ttt -T, au moins pour les compilateurs comme g ++ qui sont divisés en de nombreux processus.

2
Phil Miller