Discussion :

[Idelways]

Le C++ se compile-t-il trop lentement ?
Oui répond Walter Bright, un développeur de compilateur qui expose les raisons de cette lenteur supposée


Walter Bright travaille dans le développement de compilateurs de C++ depuis plus de 20 ans. Et selon lui c'est un fait : la compilation du C++ est lente, trop lente. Vraiment trop lente même puisqu'elle peut aller jusqu'à durer des nuits entières.

Dans un billet, il expose les raisons qui lui semblent expliquer ce problème, un problème souvent cité comme l'une des raisons qui ont motivé le développement par Google du langage de programmation « GO ».

Walter Bright expose en tout 7 raisons, autant que le nombre (important) de phases de compilations, complètement indépendantes les unes des autres.

Il explique en substance que l'appel a #include étant textuel - et non symbolique - les appels répétés aux même sources provoqueraient leur analyse complète à plusieurs reprises, même quand #include est protégé par #ifndef.

Ce mécanisme serait d'autant plus aggravé que les développeurs auraient de plus en plus tendance à « #inclure » tout (et donc aussi n'importe quoi) surtout en programmation générique et pour l'usage des templates.

Ces critiques n'empêche pas d'aimer le langage. Au contraire, il place de nombreux espoirs dans C++1x, la nouvelle norme pour le langage C++ sur laquelle planche depuis plusieurs années maintenant, un comité de normalisation ISO (et qui pourrait s'appeler C++11).

« J'espère que des efforts seront faits pour résoudre le problème », même si cela devrait prendre « au moins 10 ans » et poser des problèmes de rétrocompatibilité.

Mais quand on aime on ne compte pas... et on sait être patient.

Non ?


La compilaton du C++ est elle véritablement aussi lente que ce que laisse entendre Walter Bright ?

Quelles sont selon vous les raisons de cette lenteur ? Comment la gérez-vous ?
Est-elle préjudiciable à votre productivité ?
Avez-vous déjà envisagé de passer à Go ou un autre langage à cause de cette lenteur ?



Source : Blog Dr.Bobb's

Lire aussi :

Quel est pour vous le défaut le plus gênant du C++ ? Un développeur chevronné fait la liste des faiblesses de son langage préféré

C ou C++ ? Quel langage choisir pour un projet sur une cible embarquée ?

Le moc (meta-object compiler) a-t-il toujours une raison d'exister, maintenant que les compilateurs ont évolué ?

Les rubriques (actu, forums, tutos) de Développez :

C++
Langages


En collaboration avec Gordon Fowler

[bioinfornatics]

Je trouve bizarre que walter bright parle du GO étant un développeur D / C++ ! Mais bon il parle bien du Go dans son blog

[chaplin]

Je travaille sur un projet en delphi de + 100 000 lignes, 10 s à la compilation.

[_skip]

Oui c'est un problème lors de la compilation mais pas seulement. Côté IDE, l'analyse de code pour l'auto-complétion est aussi très difficile tout comme le sont les fonctions de refactoring.

Il est malheureux que si peu de gens s'intéressent à D.

[HAL-9000]

@ chaplin : la longueur de code ne fait pas tout... 100 000 lignes dont l'objectif est d'afficher la valeur 1 au moniteur c'est pas la même que 100 000 lignes qui calibrent, modélisent et simulent des modèles mathématiques.

[HanLee]

@ chaplin : la longueur de code ne fait pas tout... 100 000 lignes dont l'objectif est d'afficher la valeur 1 au moniteur c'est pas la même que 100 000 lignes qui calibrent, modélisent et simulent des modèles mathématiques.

Mais ce n'est pas parce qu'un 100 000 lignes de code prend du temps à exécuter que ça prend du temps à être compilé.

Une boucle infinie...
Une boucle d'une ligne de calcul très lourde...
C'est peanuts à compiler!

[Mat.M]

Ce mécanisme serait d'autant plus aggravé que les développeurs auraient de plus en plus tendance à « #inclure » tout (et donc aussi n'importe quoi) surtout en programmation générique et pour l'usage des templates.

ce problème est contourné sous Visual Studio avec les en-têtes précompilés ( precompiled headers)

[amaury pouly]

ce problème est contourné sous Visual Studio avec les en-têtes précompilés ( precompiled headers)

Les en-têtes précompilées accélère le temps nécessaire à parser le code, c'est indéniable. Toutefois, les problèmes du C++ se situe a bien des niveau. Le plus gros des problème est sa grammaire ambiguë. Certaines expressions doivent être lu jusqu'au dernier caractère pour en déterminer ne serait-ce que le type (déclaration, affectation, ...). Et c'est sans parler du fait qu'il faut "lire" le code plusieurs fois sinon on ne peut pas connaître le type d'une expression.
Il y a ensuite le problème d'instanciation des templates puisque le compilateur ne vérifie presque rien avant l'instanciation et qu'il doit recommencer pour chaque instanciation différente.
En bref, le C++1x ne va rien changer à ce problème, c'est le langage lui-même qu'il faudrait changer

Par exemple, le D dont il est l'auteur résout ces problèmes grâce à une grammaire plus simple et une inclusion non textuelle, mais le D n'est pas parfait non plus.

[gorgonite]

Les en-têtes précompilées accélère le temps nécessaire à parser le code, c'est indéniable. Toutefois, les problèmes du C++ se situe a bien des niveau. Le plus gros des problème est sa grammaire ambiguë. Certaines expressions doivent être lu jusqu'au dernier caractère pour en déterminer ne serait-ce que le type (déclaration, affectation, ...). Et c'est sans parler du fait qu'il faut "lire" le code plusieurs fois sinon on ne peut pas connaître le type d'une expression.

GLR, ça change sur LL(1) de Pascal, mais ce n'est pas forcement imbuvable pour autant ^^

Il y a ensuite le problème d'instanciation des templates puisque le compilateur ne vérifie presque rien avant l'instanciation et qu'il doit recommencer pour chaque instanciation différente.
En bref, le C++1x ne va rien changer à ce problème, c'est le langage lui-même qu'il faudrait changer

qu'est-ce qu'il ne faut pas entendre ?

1. il est possible de simplifier BEAUCOUP les messages d'erreurs émis malgré les imbrications de templates... les concepts l'ont prouvé,
2. il existe des outils de création d'interface minimale pour la programmation par contrat dans certains analyseurs qui réaliseraient cette tâche également... et simplifierait la gestion de templates en général

donc avant de vouloir changer de langage, il faudrait essayer de le comprendre, et surtout de comprendre ce qui ralentit tant toutes évolutions de sa part

[chaplin]

@ chaplin : la longueur de code ne fait pas tout... 100 000 lignes dont l'objectif est d'afficher la valeur 1 au moniteur c'est pas la même que 100 000 lignes qui calibrent, modélisent et simulent des modèles mathématiques.

Certe, il est vrai que la compilation se fait sur une machine du même calibre que celle qui est dans tes références, cependant, j'ai pas le souvenir d'avoir compilé une librairie (KSDev, glscene, etc ..) qui prenait plus d'une minute, sauf du temps des pentium à 32Mo .

[bioinfornatics]

@gorgonite c'est juste que le D facilite grandement ce travail car géré nativement

[gorgonite]

@gorgonite c'est juste que le D facilite grandement ce travail car géré nativement

va falloir revoir votre sens de "nativement"... parce que "intégrable dans le compilo" c'est quand même pas loin du natif

après D profite de l'absence de guerres de standards et d'éditeurs "avant-gardistes"

[Klaim]

Je trouve bizarre que walter bright parle du GO étant un développeur D / C++ ! Mais bon il parle bien du Go dans son blog

Ces trois languages sont censé viser les développement système. Fondamentalement ils jouent dans la même cours, mais n'ont pas la même maturité.

après D profite de l'absence de guerres de standards et d'éditeurs "avant-gardistes"

Et perds sa crédibilité par manque de standardisation du language et de ses bibliothèque. Les deux cotés d'une même pièce.

Cela dit, ça s'améliore dans le temps des deux cotés.

Certe, il est vrai que la compilation se fait sur une machine du même calibre que celle qui est dans tes références, cependant, j'ai pas le souvenir d'avoir compilé une librairie (KSDev, glscene, etc ..) qui prenait plus d'une minute, sauf du temps des pentium à 32Mo

Essaie de compiler OGRE. A part si tu est dans des conditions optimales (machine plus que 4 coeurs, 4Gh, compilation distribuée sur une ferme de serveurs...) je vois pas comment tu peux compiler cette lib en moins d'une minute.


C'est evident que le C++ est lent a compilé, on le sait depuis longtemps. Ca m'irrite qu'on se concentre autant sur le probleme sans réfléchir a des solutions (autres que celles connues). Par exemple, le fameux commité a au moins abordé il y a quelques années la possibilité d'avoir un système de module. C'est déjà un bon pas parceque ça réglerai le problème de la compilation en ajouter des instructions (supposant un partage des symboles de l'application entière) et non des commande de pré-compilateur.

[HAL-9000]

Certe, il est vrai que la compilation se fait sur une machine du même calibre que celle qui est dans tes références, cependant, j'ai pas le souvenir d'avoir compilé une librairie (KSDev, glscene, etc ..) qui prenait plus d'une minute, sauf du temps des pentium à 32Mo

Elles n'ont pas toutes ma cylindrée
Sinon j'ai effectivement mélangé Compilation avec Execution, mea culpa...

[kaymak]

Je ne suis pas un spécialiste barbu du c++, juste un nouvel utilisateur depuis peu, quelques heures à mon actif.

Et je dois bien dire que les include sont infâmes. D'ailleurs je ne comprend pas pourquoi il faut que j'indique l'usage de la classe <machin>, c'est écris dans le code, le compilo n'à qu'à lire pour le déterminer, rien de bien sorcier.

Les seules raisons qui devraient me pousser à faire cette définition explicite seraient
de vouloir forcer une version, mais d'autres mécanismes doivent déjà exister.
d'utiliser des types "dynamique", mais est ce qu'on s'en sert si souvent ? Et est ce que lorsqu'on s'en sert ce n'est pas au développeur de l'indiquer explicitement.

Par ailleurs, au sein d'un même projet genre gui, pas trop gros cela va de soit, on pourrait avoir un seul include sa éviterait les duplications...

De la même manière le compilateur n'émet pas de message lorsque une librairie est chargée inutilement.

Enfin je ne comprend pas pourquoi ce genre d'update devrait attendre une dizaine d'années.... C'est pas une tâche du compilateur sa ? Suffit pas de faire un patch?....

De mon oeil de novice qui n'y connait pas grand chose, tout cela me laisse un goût de jm'en foutisme, particulièrement lorsque je lis ceci :

Il explique en substance que l'appel a #include étant textuel - et non symbolique - les appels répétés aux même sources provoqueraient leur analyse complète à plusieurs reprises

a plus

[vanquish]

Bonjour,

Je travaille sur un projet en delphi de + 100 000 lignes, 10 s à la compilation.

C'est aussi parce qu'en Delphi, le développeur se cogne une grosse part du boulot, fait par le compilateur dans les autres langages.

Je ne dit pas que c'est mal (je trouve le Delphi très lisible), mais Delphi est très verbeux.
Une partie de tes 100.000 ne sont QUE de la déclaration et n'effectue aucun traitement.

Cela permet à Delphi de réduire le nombre de passes, mais oblige, lors de la saisie du code, à de nombreux aller/retour entre les sections interface/implémentation - ce qui, comme des temps de compilation longs, n'est pas génial en terme de productivité (même si l'IDE aide).

Les références circulaires, sont interdite, ce qui oblige à passer par des type ancêtres générique (la VCL est plein de TObject qui dans les fait désignent des objets de bien plus haut niveau), ce qui n'est pas génial non plus.

Bref, le compilateur est rapide, mais il y a une contre-partie pour le développeur.

[agrosjea]

Je me demandais si Make ne pouvais pas lancer la compilation des fichier .o en parallèle, avec le multicoeur on gagnerait pas mal de temps !

Edit : magnifique -j permet de spécifier le nombre de tâches à lancer en parallèle !!!!

[gorgonite]

Et je dois bien dire que les include sont infâmes. D'ailleurs je ne comprend pas pourquoi il faut que j'indique l'usage de la classe <machin>, c'est écris dans le code, le compilo n'à qu'à lire pour le déterminer, rien de bien sorcier.

...

Enfin je ne comprend pas pourquoi ce genre d'update devrait attendre une dizaine d'années.... C'est pas une tâche du compilateur sa ? Suffit pas de faire un patch?....

De mon oeil de novice qui n'y connait pas grand chose, tout cela me laisse un goût de jm'en foutisme, particulièrement lorsque je lis ceci :

tu ne comprends pas... ça se voit au premier coup d'oeil. malgré cela, tu émets des jugements (l'informatique étant le seul domaine où le premier individu passant plus d'une heure sur un ordinateur se permet d'expliquer son métier à ceux qui bossent dessus depuis des années, quoi de plus normal )

revenons à nos moutons... avant de vouloir déterminer ce qui incombe au compilateur, et ce qui doit être explicitement effectué par l'utilisateur, il faudrait déjà comprendre ce que le langage souhaite faire, vers quel public il se destine, et surtout ce que ça coûterait "d'alléger certaines étapes si ingrates aux yeux d'un novice"

déjà C++ est un langage utilisé à grande échelle, et ne dépendant pas exclusivement d'un éditeur... il y a donc un comité de "standardisation" & cie, qui empêche en théorie que tout le monde fasse n'importe quoi dans son coin, mais rien n'empêche un éditeur de s'adapter en fonction de contraintes/politiques internes dans la pratique (cf g++ 3.* , VC++ 6, etc)
les normes prennent du temps à être établies, et des guerres d'influence / de lobby / de personnes sont parfois primordiales sur l'aspect technique des "études".
donc inutile de comparer à Delphi, Java, Go & cie de ce côté... revenez à la "guerre des Pascal" à l'époque où Borland/Corel/Embarcadero (comme le KGB j'ai un peu de mal à me souvenir de son appellation du jour) ne contrôlait ce marché


après clairement, il y a des opérations purement syntaxiques à première vue inutiles... mais un bon IDE le fera pour vous
certains détails barbants subsistent, et les choses avancent à leur rythme... style auto dans C++0/1/2X (on sait jamais je prends mes précautions ), l'idée des concepts qui a fini en guerre de logiciens pour un lambda-prolog dans le moteur de templates (je caricature à peine )

Par ailleurs, au sein d'un même projet genre gui, pas trop gros cela va de soit, on pourrait avoir un seul include sa éviterait les duplications...

De la même manière le compilateur n'émet pas de message lorsque une librairie est chargée inutilement.

ok dans l'idée pour cette partie

[Aurelien.Regat-Barrel]

Edit : magnifique -j permet de spécifier le nombre de tâches à lancer en parallèle !!!!

Il suffit de lire l'article de l'auteur pour l'apprendre Il parle aussi des entêtes précompilées.

Personnellement je vois pas trop le but du tsoin tsoin. Avec les templates et la metaprogrammation, le compilateur peut être utilisé comme générateur de code. Forcément, cela a un cout au moment de la compilation.

Comparer avec Delphi c'est comparer des choux avec des chemises. Le Pascal Delphi a été conçu dès l'origine pour être compilable en une seule passe. Ca fait partie de son design et c'est entre autre ce qui a fait son succès. Malgré ça, Delphi c'est mort et quasiment enterré. Cherchez l'erreur!

Jusqu'ici les solutions aux temps élevés de compilation ont été techniques, et tout montre que ça va encore continuer à l'être. Les linkers et compilateurs deviennent multi-threadés. Et y'a des projets comme ccache et IncrediBuild (build distribuées) qui permettent d'obtenir des temps très corrects.

Mais comme toujours avec le C++, toute cette artillerie lourdre montre son intérêt sur de gros projets. C'est sur que pour faire un simple hello world, le C++ apparait vite comme archaïque.

Suffit pas de faire un patch?....

Et bien il suffit que tu le fasses, ce patch! :p

[Paul TOTH]

Bonjour,

C'est aussi parce qu'en Delphi, le développeur se cogne une grosse part du boulot, fait par le compilateur dans les autres langages.

je ne vois pas bien de quoi tu veux parler...en C++ comme en Delphi on déclare les classes on les crées et les détruit (sauf à utiliser des classes statiques en C++), mais au lieu de déclarer, initialiser et invoquer dans une même instruction, le Pascal (et donc Delphi) oblige à déclarer d'un côté, initialiser et ensuite invoquer...il est donc plus verbeux certes, mais il n'y a rien de plus ou de moins qu'en C++. D'ailleurs les propriétés dans Delphi peuvent directement faire référence à un champ privé sans avoir à déclarer des get/set

Je ne dit pas que c'est mal (je trouve le Delphi très lisible), mais Delphi est très verbeux.
Une partie de tes 100.000 ne sont QUE de la déclaration et n'effectue aucun traitement.

que ce soit de la déclaration ou du code, se serra toujours plus rapide à compiler sous Delphi que le même code C++ car le compilateur sait toujours à quoi il a affaire...en c++ on pourra toujours tomber sur une référence externe ambiguë ou non résolue au moment de l'édition de liens.

Cela permet à Delphi de réduire le nombre de passes, mais oblige, lors de la saisie du code, à de nombreux aller/retour entre les sections interface/implémentation - ce qui, comme des temps de compilation longs, n'est pas génial en terme de productivité (même si l'IDE aide).

l'IDE offre en effet bon nombre de raccourcis pour ce point (Ctrl + Alt + C et hop ! l'interface est reportée en implementation)

Les références circulaires, sont interdite, ce qui oblige à passer par des type ancêtres générique (la VCL est plein de TObject qui dans les fait désignent des objets de bien plus haut niveau), ce qui n'est pas génial non plus.

c'est un prix que j'accepte pour une compilation ultra rapide, et c'est un point qui me pose très rarement problème

Bref, le compilateur est rapide, mais il y a une contre-partie pour le développeur.

Il n'est pas "que" rapide : une compilation de plusieurs heures sous Delphi ça n'existe pas ! Et c'est ce rapport gain de compilation/perte en déclaration qui me fait préférer de loin le Pascal aux autres langages compilés.