temps de liaison de profil avec gcc/g ++ et ld

Question

J'utilise g ++ pour compiler et lier un projet composé d'environ 15 fichiers sources C++ et de 4 fichiers objets partagés. Récemment, le temps de liaison a plus que doublé, mais je n'ai pas l'historique du makefile à ma disposition. Existe-t-il un moyen de profiler g ++ pour voir quelle partie de la liaison prend beaucoup de temps?

Modifier: Après avoir remarqué que le fichier makefile utilisait des optimisations -O3 tout le temps, j'ai réussi à réduire de moitié le temps de liaison en supprimant ce commutateur. Y a-t-il un bon moyen que j'aurais pu trouver sans essais et erreurs?

Éditer: Je ne suis pas vraiment intéressé par le profilage de la façon dont fonctionne ld. Je suis intéressé de savoir comment je peux faire correspondre les augmentations de temps de liaison à des commutateurs de ligne de commande spécifiques ou des fichiers objets.

Answer 1

gcc et g ++ prennent tous deux en charge l'indicateur verbeux -v, ce qui leur permet d'afficher les détails de la tâche en cours.

Si vous êtes vraiment intéressé par profiler vraiment les outils, vous voudrez peut-être vérifier Sysprof ou OProfile.

Answer 2

Le profilage g++ s'avérera futile, car g++ n'effectue pas de liaison, l'éditeur de liens ld le fait. Le profilage ld ne vous montrera probablement rien d'intéressant, car le temps de liaison est le plus souvent dominé par les E/S disque, et si votre lien ne l'est pas, vous ne savez pas quoi faire des données de profilage, à moins que vous comprenez ld internes.

Si votre temps de lien est perceptible avec seulement 15 fichiers dans le lien, il y a probablement quelque chose de mal avec votre système de développement [1]; soit il a un disque qui est sur ses dernières jambes et réessaie constamment, ou vous n'avez pas assez de mémoire pour effectuer le lien (la liaison est souvent RAM-intensive), et votre système échange comme fou. En supposant que vous êtes sur un système basé sur ELF, vous pouvez également essayer le nouvel éditeur de liens gold (partie de binutils), qui est souvent plusieurs fois plus rapide que le GNU ld. [1] Mes liens typiques impliquent des milliers d'objets, produisent des exécutables 200 + MB, et finissent en moins de 60 secondes.

Answer 3

Si vous venez d'atteindre votre limite de RAM, vous serez probablement en mesure d'entendre le disque fonctionner, et un moniteur d'activité du système vous le dira. Mais si la liaison est toujours liée au processeur (c'est-à-dire si l'utilisation du processeur est encore élevée), ce n'est pas le problème. Et si la liaison est liée à l'E/S, le coupable le plus courant peut être une information d'exécution. Jetez un oeil à la taille de l'exécutable de toute façon.

Pour répondre à votre problème d'une manière différente: utilisez-vous un modèle lourd? Pour chaque utilisation d'un modèle avec un paramètre de type différent, une nouvelle instance de l'ensemble du modèle est générée, ce qui vous donne plus de travail pour l'éditeur de liens. Pour que cela soit vraiment perceptible, cependant, vous devez utiliser une bibliothèque très lourde sur les modèles. Un grand nombre de projets du projet Boost se qualifient - j'ai utilisé le code basé sur un template pour utiliser Boost :: Spirit avec une grammaire complexe. Et ~ 4000 lignes de code compilées à 7,7M d'exécutable - en changeant une ligne doublé le nombre de spécialisations requises et la taille de l'exécutable final. Inline a beaucoup aidé, ce qui a permis d'atteindre 1,9 million de résultats.

Les bibliothèques partagées peuvent causer d'autres problèmes, vous pouvez regarder la documentation de -fvisibility = hidden, et cela améliorera quand même votre code.A partir de manuel de GCC pour -fvisibility:

Using this feature can very substantially 
improve linking and load times of shared object libraries, produce 
more optimized code, provide near-perfect API export and prevent 
symbol clashes. It is *strongly* recommended that you use this in 
any shared objects you distribute. 

En fait, l'éditeur de liens doit normalement soutenir la possibilité de l'application ou pour d'autres bibliothèques pour passer outre les symboles définis dans la bibliothèque, alors que généralement ce n'est pas le but usage. Notez que cela n'est pas gratuit mais cela nécessite des changements de code (triviaux). Le lien suggéré par les docs est: http://gcc.gnu.org/wiki/Visibility