Construire Boost-powered solution dans VS

Question

Boost rock, c'est super et extrêmement puissant, mais je déteste chaque fois que je construis une solution dans mon Visual Studio 7.1.

Il semble que Boost ait un impact sur le temps de construction (pas positif). Je ne peux pas retirer toute l'utilisation de Boost de mon projet pour comparer les temps de construction mais je l'ai essayé sur de petits projets et la différence est significative.

Je suppose que le problème est que Boost se compose de milliers de fichiers d'en-tête qui se comprennent très largement. Ainsi, lorsque j'inclus boost/function.hpp dans mon fichier d'en-tête, cela peut entraîner l'inclusion de centaines d'en-têtes Boost.

Y at-il quelqu'un qui a vécu la même chose? Des idées pour le résoudre?

pensées approximatives:

1. boost Ajouter aux en-têtes précompilés? Au moins, ils seront analysés et conservés dans un seul fichier
2. Est-ce que l'instantination explicite pour certains modèles Boost?
3. Préparez les en-têtes Boost en quelque sorte?
4. Ne pas inclure Boost à des fichiers d'en-tête (sons irréel)
5. ...

PS. Yep, Boost utilise aussi des templates très difficiles à compiler, je suppose, donc des milliers de fichiers d'entêtes ne sont pas le seul problème.

Answer 1

Naturellement, y compris coup de pouce conduit à de plus longs temps de compilations - tout comme y compris toute bibliothèque fait. Le fait d'être (pour la plupart) une bibliothèque de modèles conduit à une pénalité de performance assez importante car toute la logique est implémentée dans les en-têtes.

1. J'ai eu de bons résultats, y compris (un sous-ensemble de) booster dans les en-têtes précompilés. Cependant, je crois que le gain est le plus grand avec MSVC 9. Sur MSVC 7, j'ai vu plusieurs rapports disant que les en-têtes précompilés de modèles conduit souvent à des pénalités de performance. Un autre aspect crucial déterminant si vous allez voir le gain de performance est d'inclure les en-têtes appropriés dans l'en-tête précompilé. N'incluez que les en-têtes que vous utilisez fréquemment et assurez-vous qu'ils ne sont jamais changés (pensez trois fois avant d'inclure vos propres en-têtes ici)

2. Je ne sais pas si l'instantané explicite a un effet, même si j'en doute. Si quelqu'un a vu des résultats à ce sujet (quel que soit le compilateur), ce serait très intéressant.

3. "Préparer" les en-têtes de boost ressemble à les modifier, ce qui me semble être une très mauvaise idée. Vous ne voulez pas finir par maintenir des en-têtes personnalisés ...

4. Peut-être pas aussi irréel que vous pourriez le penser. Utilisez toujours autant de forward declarations que possible pour réduire l'empreinte de chaque fichier d'en-tête. Pensez à utiliser le modèle Pimpl pour éviter d'inclure des en-têtes boost qui ne sont pas reflétés dans l'interface publique de votre classe (offtopic: je considère que Pimpl est souvent inutile.) J'essaye plutôt de découper les classes en plus petits morceaux. plus propre "mode"). N'ayez pas peur d'inclure des classes générales et communes (par exemple shared_ptr) tant que vous êtes cohérent dans l'utilisation de ces classes (si vous les utilisez dans toutes vos classes, vous ne verrez pas beaucoup de gain pour les cacher d'un en-tête) .

5. La mise à niveau de MSVC (pour prendre en charge des générations parallèles) vous aidera. Cependant, c'est toujours un problème en C++. Pour minimiser le problème, vous devez être très strict et suivre les directives pour réduire l'empreinte de vos en-têtes. De temps en temps, vous devriez regarder à travers les clauses d'inclusion et assurez-vous qu'il n'y a rien d'inutile inclus. Si vous êtes la liste des inclus dans l'en-tête devient long vous faites probablement quelque chose de mal - la plupart comprend seulement être dans le cpp.

Answer 2

Comme vous l'avez mentionné dans votre message, le code de boost contient beaucoup de code de modèle qui nécessite beaucoup de cycles CPU pour la compilation. Le surcoût de plusieurs fichiers d'en-tête est très faible par rapport à cela. La première chose que vous devez faire est de trouver quel fichier d'en-tête ou quelle ligne de code est responsable du retard de compilation. Souvent, ce n'est pas l'inclusion du fichier d'en-tête, mais l'utilisation de l'une de ses classes/fonctions dans votre propre code qui cause le retard. Vous pouvez isoler le code responsable en commentant des parties de votre code jusqu'à ce que la compilation soit à nouveau rapide, puis en décommentant vos morceaux de code jusqu'à ce que la compilation soit à nouveau lente. Ensuite, vous pouvez décider si vous voulez remplacer le code lent par autre chose ou non. C'est à vous de peser les avantages et les inconvénients ici ou la vitesse de compilation vs nifty boost code.

Il y a quelques autres choses que vous pouvez faire aussi bien:

• Nettoyons déclarations incluent non nécessaire, surtout dans vos têtes
• dans vos fichiers d'en-tête, remplacer comprend des déclarations avant (si possible)
• un ordinateur plus rapide: D

Answer 3

y compris les fichiers d'en-tête Boost seulement quand ils sont vraiment nécessaires est logique. Les en-têtes, y compris les autres en-têtes, sont source de stress pour les E/S et ont un impact important sur la compilation. La déclaration vers l'avant aide à un certain point, mais avec Boost cela peut être une vraie douleur. L'utilisation de gardes externes dans les fichiers d'en-tête évite un chargement inutile.Comme ceci:

#ifndef BOOST_SHARED_PTR_HPP_INCLUDED 
# include <boost/shared_ptr.hpp> 
#endif 

Une autre façon d'éviter la cascade d'en-tête est d'utiliser "pimpl"-idiom, surtout lorsqu'ils traitent avec des classes complexes. Ensuite, des éléments Boost complexes peuvent être inclus et utilisés uniquement par cette unité de compilation. L'inconvénient est que l'interface devrait être conçue de sorte qu'aucune substance spécifique de Boost n'est exigée. Cependant, briser les dépendances pourrait être une bonne chose aussi.

Answer 4

J'aime stimuler aussi beaucoup

• Utilisez l'en-tête précompilé comme vous avez dit (qui apporte plus)
• Lorsque vous utilisez les bibliothèques liées vérifier si vous avez vraiment besoin d'eux (liaison est également assez lent)

Un autre indice peut-être stupide, mais était la principale source de perte de performance sur mon ordinateur:

• vérifier si votre antivirus fait un sur l'accès-scan et le désactiver pour les répertoires source en-tête & (coup de pouce et vos projets)