Nous avons une grande solution Visual Studio 2005 C ++ / MFC, 1 projet avec environ 1300 fichiers source (donc environ 650 .H et 650 fichiers .cpp). Nous utilisons également Boost et quelques autres bibliothèques (COM: MSXML, Bureau).
Récemment, j'ai ajouté quelques instances de boost :: multi_index pour accélérer un peu les choses. Tout cela compile la plupart du temps. Mais maintenant, lorsque je fais une reconstruction complète (libération), je reçois des accidents du compilateur à quelques modules. P>
Fatal Error C1060: "compiler is out of heap space"
3 Réponses :
Si 1300 fichiers prennent la compilation longue pour compiler, vous incluez trop de fichiers d'en-tête non nécessaires. Je suppose que les gens ont coupé et collé un tas de fichiers de tête dans un fichier de RPC sans penser quels sont les en-têtes qu'ils ont réellement besoin de sorte que les charges d'entre elles soient incluses quand elles ne devaient pas être incluses. Je devine également que vous ne déclarez pas que vous déclarez des cours où vous devriez être.
Je suggérerais que vous devez passer du temps à traverser votre projet et à supprimer des #inclut inutiles. Je suppose que cela résoudra vos problèmes de mémoire et améliorera votre heure de compilation.
Oui, il y a beaucoup d'inclut dans le projet et j'essaie de les réduire aussi. Y a-t-il un outil qui peut m'aider à identifier les modules "critiques" (ceux qui incluent la plupart des autres)?
Essayez Doxygen ( pile.nl/~dimitri/doxygen ). Citation de son manuel: # Un graphe de dépendance incluait pour chaque fichier documenté comprenant au moins un autre fichier. Cette fonctionnalité est actuellement prise en charge pour HTML et RTF uniquement. # Un graphe de dépendance inverse comprend également la présentation d'un fichier (en-tête), quels autres fichiers l'incluent. Assurez-vous simplement que le fichier de configuration du doxygen (appelé doxyfile) est pas avoir le jeu Hide_undoc_relations afin que vous obteniez une sortie pour toutes les classes / articles.
Je serais à être d'accord avec GoZ, jetez un coup d'œil à Notre solution C ++ est de cette taille approximative et utilisée pour nous amener à 50 minutes pour compiler, par analyse de fichiers d'en-tête soignée, nous l'avons eu jusqu'à 8 minutes.
Merci. J'ai également installé le Profactor IncludeManager. Maintenant, comment puis-je identifier les modules les plus critiques? Y a-t-il une méthode suggérée?
Cela fait longtemps que nous l'avons fait dans la colère, mais je pense que nous avons commencé par examiner le projet, citons la structure des détails du projet et essayant de voir s'il y avait quelque chose de manifestement erroné (inattendu inclus), puis nous avons déplacé vers des fichiers clés Nous savions que nous prenions beaucoup de temps pour compiler et examiner l'impact de la construction sur ceux-ci. Je pense qu'une fois que nous avions réglé ce qui devrait et ne devrait pas être à STDAFX.H qui a fait la plus grande différence. Vous voudrez peut-être en outre inclure davantage dans STDAFX.H si cela est inclus dans de nombreux fichiers, puis prend beaucoup de temps pour compiler.
Incredibuild (système de construction distribué pour VC ++) en plus de la gain de temps a une fonction utile supplémentaire. Il redémarrera une compilation automatiquement si la machine distante ne renvoie pas les résultats. Vous devriez donc être capable d'obtenir des constructions complètes, sans collisions dans 5 ou peut-être 10 minutes.
ci-dessus, où je mentionne "la machine à noyau unique", une machine à noyau double plus lente est signifiée. lol