Comment réduisez-vous le temps de compilation et le temps de liaison pour les projets Visual C ++ (C ++ natif)?

Comment réduisez-vous le temps de compilation et le temps de liaison pour les projets VC ++ (C ++ natif)?

Veuillez spécifier si chaque suggestion s’applique au débogage, à la publication ou aux deux.

Cela peut sembler évident pour vous, mais nous essayons d’utiliser autant que possible les déclarations avancées, même si cela nécessite d’écrire de longs noms d’espace de noms dans lesquels se trouvent les types:

// Forward declaration stuff namespace plotter { namespace logic { class Plotter; } } // Real stuff namespace plotter { namespace samples { class Window { logic::Plotter * mPlotter; // ... }; } } 

Cela réduit considérablement le temps nécessaire à la compilation sur d’autres compilateurs. En effet cela s’applique à toutes les configurations 🙂

Utilisez le motif Handle / Body (aussi appelé parfois “pimpl”, “adapter”, “decorator”, “bridge” ou “wrapper”). En isolant l’implémentation de vos classes dans vos fichiers .cpp, elles ne doivent être compilées qu’une seule fois. La plupart des modifications ne nécessitent pas de modification du fichier d’en-tête, ce qui signifie que vous pouvez apporter des modifications assez importantes en n’exigeant qu’un seul fichier à recomstackr. Cela encourage également la refactorisation et l’écriture des commentaires et des tests unitaires, car le temps de compilation est réduit. De plus, vous séparez automatiquement les problèmes d’interface et d’implémentation pour simplifier l’interface de votre code.

Si vous avez des en-têtes complexes de grande taille qui doivent être inclus dans la plupart des fichiers .cpp de votre processus de génération et qui ne sont pas modifiés très souvent, vous pouvez les précomstackr. Dans un projet Visual C ++ avec une configuration typique, il suffit simplement de les inclure dans stdafx.h. Cette fonctionnalité a ses détracteurs, mais les bibliothèques qui utilisent pleinement les modèles ont tendance à avoir beaucoup de choses dans les en-têtes, et les en-têtes précompilés sont le moyen le plus simple d’accélérer les versions dans ce cas.

Ces solutions s’appliquent à la fois au débogage et à la publication et se concentrent sur une base de code déjà volumineuse et encombrante.

Les déclarations avancées sont une solution commune.

La construction dissortingbuée, comme avec Incredibuild, est une victoire.

Pousser le code des en-têtes vers les fichiers source peut fonctionner. Les petites classes, les constantes, les énumérations, etc. peuvent commencer dans un fichier d’en-tête simplement parce qu’il aurait pu être utilisé dans plusieurs unités de compilation, mais en réalité, elles ne sont utilisées que dans une seule et peuvent être déplacées dans le fichier cpp.

Une solution que je n’ai pas lue mais que j’ai utilisée est de séparer les gros en-têtes. Si vous avez une poignée de très gros en-têtes, regardez-les. Ils peuvent contenir des informations connexes et peuvent également dépendre de nombreux autres en-têtes. Prenez les éléments qui n’ont pas de dépendances sur d’autres fichiers … des structures simples, des constantes, des énumérations et des déclarations avancées et déplacez-les de the_world.h vers the_world_defs.h . Vous pouvez maintenant trouver que beaucoup de vos fichiers sources ne peuvent désormais inclure que le the_world_defs.h et éviter d’inclure tout ce surcoût.

Visual Studio a également une option “Show Includes” qui peut vous donner une idée des fichiers source qui incluent de nombreux en-têtes et des fichiers d’en-tête les plus fréquemment inclus.

Pour les inclus très courants, envisagez de les placer dans un en-tête pré-compilé.

J’utilise Unity Builds (Screencast situé ici ).

La question de la vitesse de compilation est assez intéressante pour que Stroustrup l’a dans sa FAQ .

Nous utilisons Incredibuild de Xoreax pour exécuter la compilation en parallèle sur plusieurs machines.

Aussi un article intéressant de Ned Batchelder: http://nedbatchelder.com/blog/200401/speeding_c_links.html (à propos de C ++ sous Windows).

Nos machines de développement sont toutes quad-core et nous utilisons Visual Studio 2008 pour la compilation parallèle. Je ne suis pas certain que toutes les éditions de VS puissent le faire.

Nous avons un fichier de solution contenant approximativement 168 projets individuels et nous le compilons en 25 minutes environ sur nos machines quadricœurs, contre environ 90 minutes sur les ordinateurs portables à cœur unique que nous offrons aux étudiants d’été. Pas exactement des machines comparables mais vous avez l’idée 🙂

Avec Visual C ++, il existe une méthode, certains appellent Unity, qui améliore considérablement le temps de liaison en réduisant le nombre de modules object.

Cela implique la concaténation du code C ++, généralement en groupes par bibliothèque. Cela rend bien sûr la modification du code beaucoup plus difficile, et vous rencontrerez des collisions d’espace de noms à moins que vous ne les utilisiez correctement. Il vous empêche d’utiliser “using namespace foo”;

Plusieurs équipes de notre société ont des systèmes élaborés pour prendre en charge les fichiers C ++ normaux et les concaténer au moment de la compilation. La réduction des temps de liaison peut être énorme.

Une autre technique utile est le blobing. Je pense que c’est quelque chose de similaire à ce qui a été décrit par Matt Shaw.

En un mot, vous créez simplement un fichier cpp dans lequel vous incluez d’autres fichiers cpp. Vous pouvez avoir deux configurations de projet différentes, une ordinaire et une blob. Bien sûr, le blobing impose certaines contraintes à votre code, par exemple les noms de classes dans des espaces de noms non nommés peuvent être en conflit.

Une technique permettant de ne pas recomstackr tout le code dans un blob (comme David Rodríguez l’a mentionné) lorsque vous changez un fichier cpp – est d’avoir votre blob “fonctionnel” créé à partir de fichiers modifiés récemment et d’autres blobs ordinaires.

Nous utilisons le blobing au travail la plupart du temps, ce qui réduit le temps de création du projet, en particulier le temps de liaison.

Comstack Time:
Si vous avez IncrediBuild, le temps de compilation ne sera pas un problème. Si vous ne disposez pas d’IncrediBuild, essayez la méthode “unité de construction”. Il combine plusieurs fichiers cpp à un seul fichier cpp, ce qui réduit la durée totale de la compilation.
Heure du lien:
La méthode “unité de construction” consortingbue également à réduire le temps de liaison mais pas beaucoup. Cependant, vous pouvez vérifier si “l’optimisation globale” et “LTCG” sont activés, alors que ces indicateurs rendent le programme rapide, ils rendent le lien SLOW.
Essayez de désactiver “Whole Global Optimization” et définissez LTCG sur “Default”, le temps de liaison peut être réduit de 5/6.
(LTCG signifie génération de code de temps de liaison)