Discussion :

[Pogzy]

Bonjour,

J'ai repris un projet important en C++ sous Visual Studio 2015, il y a environ 1200 fichiers cpp et autant de .h répartie dans 13 projets dans Visual Studio, le tout générant un seul exe.
Le temps de compilation est de plus de 30 minutes.
Il y a des includes un peu dans tous les sens et j'essaye de structurer et limiter les dépendances au minimum pour gagner du temps. Chaque projet a dans ses param de compil son répertoire include et parfois celui d'autre projets.

La question que je me pose est : si je dégage tous le paramétrage des répertories d'inclusions dans les options de compilations dans tous les projets pour mettre dans chaque #include le chemin relatif in extenso est-ce que cela permettra de gagner du temps de compilation?

A priori je dirai que oui car le compilo ne devrait plus scanner des répertoires pour trouver chaque fichier mais l'ouvrir directement, mais avant d'éditer 1200 fichiers (je ferait un script pour), j'aimerai savoir si c'est un travail qui sera payant.

Est-ce que des personnes ont des éléments probants permettant d'avoir un avis pertinent sur ce sujet? voir un retour d'expérience.

Pour info, je suis sur d'autres pistes en parallèle, Incredibuild (bof), FastBuild (me paraît le plus intéressant), Ninja, Unity build (bourrin mais efficace avec Robust ou en manuel). J'ai aussi surement une autre blague dans ma compil car au bout d'un certain temps, je n'ai plus qu'un seul thread qui compile (et cela pendant plus de 15 minutes), alors qu'en début de compil tous mes cores travaillent.

Merci de m'avoir lu, et encore plus merci si vous avez des retours d'expérience.

[dalfab]

Bonjour,

Le C++ est vraiment le langage qui nécessite du temps de compilation (j'ai bossé sur projet qui demandait 30h de compilation sur un mini VAX et on avait moins de 1000 fichiers.)
Je ne pense pas que le temps de recherche de fichier d'entête soit si important que cela, même avec des milliers de répertoires contenant chacun des milliers de fichiers, en trouver mille ne devrait prendre que quelques secondes.
Mon expérience : l'antivirus ne doit pas scanner les fichier .h dans tes répertoires projet, il prend plus de CPU que le compilateur chez moi!
As-tu bien configuré la gestion des entêtes pré-compilés? Il faut mettre dedans tous les fichiers qui sont rarement ou jamais modifiés, ensuite avec juste une ligne au début de tous tes fichiers sources ça suffit.

[CedricMocquillon]

Si tu es sous visual studio et que tu peux te mettre à jour tu peux utiliser les unity build et les shared pch. Chez nous ça a apporté de gros gains sur les temps de compilation.

[koala01]

Salut,

Bonjour,

J'ai repris un projet important en C++ sous Visual Studio 2015, il y a environ 1200 fichiers cpp et autant de .h répartie dans 13 projets dans Visual Studio, le tout générant un seul exe.
Le temps de compilation est de plus de 30 minutes.
Il y a des includes un peu dans tous les sens et j'essaye de structurer et limiter les dépendances au minimum pour gagner du temps. Chaque projet a dans ses param de compil son répertoire include et parfois celui d'autre projets.

C'est un coup malheureusement classique...

Tu as presque de la chance que cela ne prenne "que" 30 minutes pour recompiler le tout

La question que je me pose est : si je dégage tous le paramétrage des répertories d'inclusions dans les options de compilations dans tous les projets pour mettre dans chaque #include le chemin relatif in extenso est-ce que cela permettra de gagner du temps de compilation?

Non, cela n'a absolument rien à voir

au contraire, cela compliquerait énormément les choses, ne serait-ce que si un jour tu en venais à décider d'une organisation différente des sous projets.

A priori je dirai que oui car le compilo ne devrait plus scanner des répertoires pour trouver chaque fichier mais l'ouvrir directement, mais avant d'éditer 1200 fichiers (je ferait un script pour), j'aimerai savoir si c'est un travail qui sera payant.

Clairement non...

Comme dit mon père :"laisse croire les béguines, elles sont spécialistes et payées pour".

Ton job à toi, c'est de travailler sur des faits. Or, voici quelques un des faits à prendre en compte:

• 1200 fichiers .cpp et autant de .h, ca fait 2400 fichiers à modifier. même à coup de script, cela représente un travail herculéen
• a priori, tous les sous projets ne disposent que des dossiers des sous-projets dont ils dépendent réellement. Cela ne devrait pas faiire plus de deux ou trois dossiers supplémentaires à utiliser pour chaque sous-projet (*)
• parce que tu crois que parcourir en chemin relatif ../../truc/include sera plus rapide
• Et si on déplace un des sous projets
• ton projet général compile très bien pour l'instant, pourquoi risquer de tout mettre à mal

(*)Il y a cependant pas mal d'aspects à prendre en compte quand on travaille avec plusieurs (sous) projets:

• Deux projets ne doivent pas présenter des "dépendances croisées" : si le projet A dépend du projet B, et que le projet B dépend du projet A, y a un problème de conception "quelque part" (cela vaut aussi pour les dépendances indirecte)
• Un projet ne doit pas dépendre de la dépendance d'une dépendance : si le projet C dépend du projet B et que B dépend dur projet A, C ne devrait pas dépendre de A
• les en-têtes précompilées peuvent diminuer sensiblement les temps de compilation
• c'est le changement d'interface d'un projet qui occasionne la re-compilation des projets qui en dépendent
• il faut, autant que possible, préférer la déclaration anticipée à l'inclusion du fichier d'en-tête correspondant dans les fichiers d'en-tête
• Il existe certains outils de "compilation partagée" si plusieurs ordinateurs sont disponibles, qui permettent de faire compiler une partie des fichiers par les ordinateurs des voisins (s'ils sont en mesure de le faire). Cela réduit sensiblement les temps de compilation quand on veut "tout recompiler depuis le début"

Est-ce que des personnes ont des éléments probants permettant d'avoir un avis pertinent sur ce sujet? voir un retour d'expérience.

J'ai travaillé sur un projet très similaire au tien en termes de sous-projets / nombre de fichiers.

Nous utilisions la compilation partagée (incredibuild) vu que l'équipe disposait de huit ordinateurs.

Nous avions recours aux déclarations anticipées chaque fois que c'était possible (et non dans le seul but d'éviter les dépendances croisées) et nous essayions "autant que possible" de limiter les dépendances entre les modules, de manière à profiter au mieux des en-têtes pré-compilées (qui doivent être ... recompilées à chaque fois que l'interface exposée par les fichiers d'en-tête pris en compte est modifiée) et surtout limiter au mieux le besoin de re-compilation au seul module modifié.

Pour les compilation "intercalaires" (tu sais, celles qui ont essentiellement pour but de s'assurer que l'on n'a pas fait une faute de frappe) et pour les tests, nous nous limitions le plus souvent à la compilation du module sur lequel nous travaillions.

Nous ne relancions une compilation plus générale qu'une fois que nous avions acquis la certitude que "tout était en ordre" au niveau du module (et des tests unitaires y afférant).

Quant au temps nécessaire pour cette compilation générale, il était généralement perçu comme l'occasion rêvée d'aller boire un café, fumer une cigarette ou zoner sur les forum

Notre système de gestion de versions concurrentes était couplé à un "build server" (jenkins) qui prenait "le temps qu'il faut" pour recompiler systématiquement le tout et exécuter tous les tests unitaires à chaque commit de notre part.

[Pogzy]

Merci à tous pour ces précisions et ces retours d'expérience.

D'après mes premiers essais avec Incredibuild, cela ne change pas grand chose à mon problème de compil, je suis avec leur support et malgré plusieurs changement de paramétrage, cela ne change rien. Sans doute qu'en passant par des machines sur le réseau cela irait mieux.

Par contre j'ai fait des tests avec FastBuild qui est Open Source, et là même en local il maximise l'utilisation de tous mes cores. Il propose aussi la compil sur des machines du réseau, je vais plutôt explorer cette piste qui me paraît plus prometteuse.

J'ai commencé à faire une passe sur tous les sources pour "nettoyer" les #include des inutiles et en redescendre le plus possible dans les cpp avec les forward déclaration. Quand j'aurait fini cette passe je commencerai à regarder les dépendances croisées qui restent.

Le projet utilise les en-tête précompilé, mais les shared pch je ne connaissait pas, peut-être que cela a déjà été mis en place.

Merci et bonnes fêtes.

[koala01]

Merci à tous pour ces précisions et ces retours d'expérience.

D'après mes premiers essais avec Incredibuild, cela ne change pas grand chose à mon problème de compil, je suis avec leur support et malgré plusieurs changement de paramétrage, cela ne change rien. Sans doute qu'en passant par des machines sur le réseau cela irait mieux.

Ah oui, l'idée d'incredibuild, c'est bel et bien d'avoir plusieurs machines qui fonctionnent en même temps, et qui partage certains de leurs processeurs (en fait de leurs coeurs) pour une compilation donnée

(et, éventuellement, avec plusieurs compilations en cour)

Par contre j'ai fait des tests avec FastBuild qui est Open Source, et là même en local il maximise l'utilisation de tous mes cores. Il propose aussi la compil sur des machines du réseau, je vais plutôt explorer cette piste qui me paraît plus prometteuse.

Aussi

J'ai commencé à faire une passe sur tous les sources pour "nettoyer" les #include des inutiles et en redescendre le plus possible dans les cpp avec les forward déclaration. Quand j'aurait fini cette passe je commencerai à regarder les dépendances croisées qui restent.

Excellente idée

Le projet utilise les en-tête précompilé, mais les shared pch je ne connaissait pas, peut-être que cela a déjà été mis en place.

Attention, les en-tête pré compilées, ca peut être très utile et ... particulièrement merdique, selon ta manière de travailler.

Cela peut t'aider à gagner énormément de temps si la plupart de tes modules sont "suffisamment stables" que pour ne pas devoir être modifiés trop régulièrement (surtout au niveau des fichiers d'en-tête, bien sur)

Par contre, si tu es dans un phase de développement active, avec ajout de nouvelles fonctionnalités et refactoring à tout va, les en-têtes pré compilées devront ... être regénérées à chaque modification d'un des fichiers pris en compte pour les générer (ou à chaque ajout d'un nouveau fichier à utiliser pour le faire).

Et ca, ca prend malgré tout un temps bête, qui peut te faire perdre tout le bénéfice qu'il peut y avoir à utiliser les en-tête pré compilées