Dans cet article, nous allons couvrir des trucs et astuces sur la façon dont vous pouvez optimiser vos projets C++Builder pour les compiler aussi vite que possible. Bien que nous passions certainement du temps à examiner les optimisations destinées à être utilisées avec TwineCompile, certaines de ces astuces s’appliquent à C++Builder en général.

C++Builder et TwineCompile incluent de nombreuses fonctionnalités conçues pour optimiser la vitesse de compilation, mais elles doivent souvent être ajustées car chaque projet est unique et a des conditions et une configuration différentes. Nous examinerons divers conseils et quand et comment les appliquer à différents types et structures de projets.

Astuce n°1 – Compilation de ficelle

La première astuce est simple : commencez à utiliser TwineCompile ! TwineCompile est un plugin IDE qui s’intègre dans C++Builder et ajoute le multi-threading, la mise en cache et d’autres améliorations puissantes aux compilateurs C++Builder (à la fois Classic et CLANG). Dans certains cas, la simple installation de TwineCompile permettra aux projets de se compiler 50 fois plus rapidement sur les postes de travail de construction de dernière génération.

TwineCompile est disponible gratuitement pour tous les utilisateurs de C++Builder 10.4.1+ avec un abonnement de mise à jour actif via le gestionnaire de packages GetIt. Cela devrait être le premier arrêt dans la quête de temps de compilation plus rapides, car vous pouvez profiter de ces améliorations de performances sans avoir à apporter une seule modification à la structure ou aux fichiers de votre projet (contrairement aux conseils suivants).

Pour obtenir TwineCompile, ouvrez le gestionnaire de packages GetIt dans l’IDE et recherchez TwineCompile. Suivez les instructions pour l’installer.

L’intégration IDE de TwineCompile accrochera automatiquement les commandes IDE Compile/Make/Build pour invoquer TwineCompile au lieu du processus de construction de l’IDE. Cela vous permet de continuer à utiliser l’IDE comme vous le faites aujourd’hui et de profiter pleinement des performances de compilation offertes par TwineCompile.

TwineCompile Trick #2 – CLANG Powered PCH (en-têtes précompilés)

C++Builder possède depuis longtemps une arme secrète qui peut fonctionner par magie sur des temps de compilation lents. Souvent, l’amélioration la plus efficace consiste à configurer et à utiliser correctement les en-têtes précompilés sur un projet. L’introduction du compilateur CLANG a considérablement amélioré cette fonctionnalité et l’a rendue beaucoup plus facile à utiliser. Si votre projet utilise actuellement le compilateur CLANG, je vous recommande fortement de profiter de la prise en charge de PCH dans CLANG car cela fera une énorme différence dans vos temps de compilation. Si votre projet utilise toujours le compilateur Classic, je vous recommande de le mettre à jour pour utiliser le compilateur CLANG – vous aurez non seulement la possibilité d’utiliser un compilateur C++ moderne et conforme aux normes avec prise en charge de C++v17, mais vous pouvoir également utiliser le système CLANG PCH.

Le concept derrière les en-têtes précompilés est assez simple : prenez un ensemble d’en-têtes qui sont utilisés dans la plupart (sinon toutes) des unités d’un projet et compilez-les dans une représentation binaire. Lorsqu’une unité du projet inclut ces en-têtes précompilés, le compilateur n’a pas à retraiter/compiler les en-têtes à partir de zéro, mais peut simplement charger la représentation pré-compilée à partir du disque et passer à la compilation du code dans l’unité. .

Une certaine discipline est requise car l’ordre des en-têtes dans chaque unité doit être identique pour garantir que le compilateur peut utiliser l’en-tête précompilé. De plus, l’en-tête précompilé ne doit pas contenir d’en-têtes fréquemment modifiés, car la surcharge de compilation des en-têtes est assez importante et vous perdrez tout l’avantage de l’en-tête précompilé s’il doit être reconstruit tout le temps.

1. Commencez par analyser votre projet et identifier les en-têtes que la plupart des unités incluent. Cela peut nécessiter une réorganisation pour que la plupart ou la totalité des unités incluent le même ensemble d’en-têtes. Notez que, y compris les frais supplémentaires, inutilisés,

les en-têtes n’ont pas d’effet négatif, donc si certaines unités n’utilisent pas tous les en-têtes, tout va bien. Plus il y a d’en-têtes précompilés, plus il sera efficace pour améliorer vos temps de compilation.

• Si votre projet possède déjà un fichier d’en-tête PCH (tel que le fichier PCH .h généré automatiquement par l’IDE pour les nouveaux projets), passez à l’étape n°6.
• Si votre projet n’a pas de fichier d’en-tête PCH (comme le fichier PCH .h généré automatiquement par l’EDI pour les nouveaux projets), ajoutez un nouveau fichier d’en-tête au projet :

• Enregistrez le nouveau fichier d’en-tête avec un nom descriptif tel que ProjectNamePCH.h
• Cliquez avec le bouton droit sur le fichier d’en-tête dans le volet Projets et sélectionnez l’option Utiliser pour la précompilation :

• Ouvrez ce fichier d’en-tête de précompilation et placez toutes les instructions d’inclusion que vous avez collectées à l’étape 1. Par example:

#include  <vcl.h>

#include  <tchar.h>

• Parcourez toutes les unités de votre projet et supprimez les instructions #include qui font référence aux en-têtes situés dans l’en-tête PCH. En haut de chaque unité, avant toute autre instruction, placez l’instruction pragma suivante pour indiquer au compilateur que l’unité n’ajuste pas l’en-tête précompilé :

#pragma  hdrstop

• Ouvrez les options du projet, accédez à la section En-têtes précompilés sous le compilateur C++ et sélectionnez Générer et utiliser pour l’option d’utilisation de PCH
• Construire le projet. Il passera un certain temps à compiler le fichier d’en-tête PCH dans la représentation binaire, puis les unités suivantes seront compilées beaucoup plus rapidement, car ces en-têtes n’auront plus à être traités pour chaque unité encore et encore.

Astuce n°3 – PCH à en-tête unique TwineCompile pour le compilateur Classic

Si votre projet utilise toujours le compilateur Classic et que vous ne parvenez pas à le migrer vers le nouveau compilateur CLANG, il est toujours possible de gagner en vitesse de compilation en utilisant des en-têtes précompilés grâce au compilateur classique doté d’un système PCH incroyablement puissant. TwineCompile a été conçu pour tirer pleinement parti de ce système et organise le processus de génération de sorte que le compilateur classique soit automatiquement appelé avec les bons paramètres pour chaque fichier utilisant l’en-tête précompilé.

Contrairement au compilateur CLANG, le compilateur classique est conçu pour générer et utiliser l’en-tête précompilé dans le cadre de la compilation des fichiers sources normaux. Aucune étape de compilation distincte n’est requise pour compiler un fichier qui a été désigné comme fichier d’en-tête précompilé.

Il existe deux façons de configurer un projet pour utiliser un PCH à en-tête unique avec le compilateur classique :

1. Utilisation d’une commande d’injection pour inclure automatiquement le fichier PCH à en-tête unique dans chaque unité dans le cadre du processus de compilation.
2. Ajout manuel de l’instruction #include pour le fichier PCH à en-tête unique en haut de chaque unité.

La première approche est évidemment la plus simple car elle veille à ce que l’en-tête soit disponible automatiquement dans chaque unité. La deuxième approche peut être utile car l’en-tête est en fait inclus dans chaque unité, il est donc disponible pour la navigation et d’autres utilisations telles que l’outil d’analyse de code.

1. Comme pour les étapes CLANG, commencez par analyser votre projet et identifier les en-têtes que la plupart des unités incluent.

Cela peut nécessiter une réorganisation pour que la plupart ou la totalité des unités incluent le même ensemble d’en-têtes. Notez que l’inclusion d’en-têtes supplémentaires inutilisés n’a pas d’effet négatif, donc si certaines unités n’utilisent pas tous les en-têtes, c’est parfaitement bien. Plus il y a d’en-têtes précompilés, plus il sera efficace pour améliorer vos temps de compilation.

• Créez un nouveau fichier d’en-tête dans votre projet :

• Enregistrez le nouveau fichier d’en-tête avec un nom descriptif tel que ProjectNamePCH.h
• Ouvrez ce fichier d’en-tête de précompilation et placez toutes les instructions d’inclusion que vous avez collectées à l’étape 1. Par example:

#include  <vcl.h>

#include  <tchar.h>

5a. Approche A – si vous souhaitez utiliser la fonctionnalité d’injection, ouvrez les options du projet, accédez à la section En-têtes précompilés sous C++ Compiler et entrez le nom du fichier d’en-tête dans l’option d’en-tête Inject :

5b. Approche B – si vous souhaitez ajouter manuellement l’en-tête dans vos unités, placez l’instruction #include pour ce fichier d’en-tête suivie d’une ligne #pragma hdrstop tout en haut de toutes les unités. Par example:

#include  "ProjectNamePCH.h"

#pragma  hdrstop

• Ouvrez les options du projet, accédez à la section En-têtes précompilés sous C++ Compiler :

6a. Sélectionnez l’option Générer et utiliser pour l’utilisation de PCH. Cela indique à TwineCompile d’utiliser le premier fichier de code source pour générer le fichier PCH et de l’utiliser pour toutes les unités suivantes.

6b. Sélectionnez l’option Cacher les en-têtes précompilés

6c. Entrez un nom pour le fichier PCH généré dans l’option Nom de fichier PCH. Par exemple : Projet.csm. Ce fichier contiendra les données binaires compilées à partir de l’en-tête sélectionné comme en-tête pré-compilé.

Les options devraient ressembler à ceci :

• Construire le projet. TwineCompile ajustera automatiquement les options du compilateur pour les fichiers en cours de compilation afin que le fichier PCH soit généré et utilisé dans le cadre du processus de compilation, avec une amélioration significative des temps de compilation.

Astuce n°4 – TwineCompile PCH automatique pour le compilateur Classic

Pour les projets qui ne peuvent pas être migrés vers le compilateur CLANG et n’ont pas la structure de projet pour prendre en charge un seul fichier PCH qui fonctionnera pour toutes les unités, l’espoir n’est pas perdu. Il existe des fonctionnalités PCH avancées dans le compilateur Classic, associées à TwineCompile, qui offrent la plupart des avantages de performances d’un en-tête précompilé réglé pour ces types de projets. Le compilateur Classic prend en charge le concept d’un en-tête pré-compilé « adaptatif » (mes mots, pas la description officielle) qui est continuellement créé et ajusté dans le cadre d’une construction de projet pour prendre en charge le

différentes variantes d’en-têtes que les unités du projet peuvent utiliser. L’astuce consiste à le faire fonctionner dans votre projet et c’est là qu’intervient TwineCompile.

1. Ouvrez les options du projet, accédez à la section En-têtes précompilés sous C++ Compiler :

1a. Sélectionnez l’option Générer et utiliser pour l’utilisation de PCH. Notez que ce projet n’a aucune sorte de structure PCH, donc normalement cette option causerait plus de problèmes qu’elle n’en résoudrait.

1b. Sélectionnez l’option Cacher les en-têtes précompilés

1c. Entrez un nom pour le fichier PCH généré dans l’option Nom de fichier PCH. Par exemple : Projet.csm. Ce fichier contiendra les données binaires compilées à partir de l’en-tête sélectionné comme en-tête pré-compilé.

Les options devraient ressembler à ceci :

• Ouvrez les options TwineCompile dans le menu TwineCompile, accédez à En-têtes précompilés et sélectionnez l’option « Utiliser le fichier PCH pour chaque thread ». Cliquez sur OK.

• Construire le projet. TwineCompile ajustera automatiquement les options du compilateur pour chaque fichier afin qu’ils puissent générer et utiliser un fichier PCH qui s’adaptera aux différentes variantes des en-têtes inclus dans chaque unité. Les performances ne seront pas aussi bonnes qu’une configuration PCH appropriée, mais seront nettement meilleures que si PCH n’était pas utilisé du tout.

TwineCompile Trick #5 – Optimiser la mise en page de votre projet

Ou pour dire cette astuce autrement – en minimisant le nombre de fichiers qui doivent être compilés lorsqu’une modification est apportée, mais en équilibrant cela par rapport au temps nécessaire pour lier.

Une tactique courante utilisée pour optimiser les temps de compilation C++ consiste à diviser les projets en de nombreuses petites bibliothèques ou packages. L’idée est que lorsqu’un code est modifié, seuls les quelques fichiers de ce projet devront être recompilés. La bibliothèque recompilée peut simplement être reconnectée avec les autres bibliothèques pour former le résultat final.

Il y a deux raisons pour lesquelles c’est souvent une mauvaise idée, surtout si vous utilisez TwineCompile :

1. Vous échangez le temps de compilation avec le temps de liaison. Les conseils qui recommandent cette approche sont généralement orientés vers les compilateurs C++ plus lents tels que gcc, où le temps de liaison est beaucoup plus rapide que les temps de compilation très lents. Il peut donc être utile de décharger le travail sur l’éditeur de liens. Les compilateurs C++Builder (CLANG et Classic) sont assez rapides pour les compilateurs C++, donc l’ajout de 15 étapes de liaison pour éviter de compiler 30 fichiers C++ entraîne souvent une perte de performances significative.

• La liaison est un processus en série. La compilation est parallèle. Lorsque vous utilisez TwineCompile, les fichiers C++ sont compilés en parallèle, donc plus il y a d’unités qui peuvent être compilées simultanément, plus les performances peuvent être obtenues. Un seul projet avec 200 unités C++ et une seule étape de liaison sera construit beaucoup plus rapidement que 10 projets avec 20 unités C++, chacun avec sa propre étape de liaison.

Comme pour la plupart des choses dans la vie, il y a un compromis où une structure de projet divisée a du sens. Malheureusement, il n’y a pas de bonne réponse unique sur la façon dont un projet doit être structuré, je vais donc vous laisser les lignes directrices suivantes :

1. Minimisez le nombre de fichiers à compiler pour toute modification de la source.
2. Minimisez le nombre de bibliothèques, de packages ou d’applications à lier. Même les bibliothèques statiques, bien qu’assez rapides à lier, ont une surcharge.
3. Optimisez vos ressources processeur. L’éditeur de liens n’utilisera qu’un seul cœur, 16 fichiers C++ sur un processeur 8 cœurs + HT utiliseront les 16 cœurs logiques. Donc, la compilation de ces 16 fichiers peut utiliser 16 fois plus de ressources que l’éditeur de liens.

Astuce n°6 – Compiler SORTA

L’une des fonctionnalités les plus puissantes de TwineCompile est son système de compilation automatique en arrière-plan. Essentiellement, cette fonctionnalité compile automatiquement vos fichiers de code source modifiés en arrière-plan, de sorte que lorsque vous cliquez sur Créer ou Exécuter, il n’y a aucun fichier à compiler, tout est à jour et le processus de génération n’a qu’à lier l’application.

Contrairement à la plupart des astuces ci-dessus, celle-ci n’est pas directement liée à l’accélération du processus de compilation ou de construction, mais vise à réduire voire à éliminer le besoin de compiler le code source.

Pour activer la compilation SORTA, ouvrez les options TwineCompile, accédez à la section Compilation SORTA et sélectionnez l’option Activer la compilation SORTA :

Un certain nombre de déclencheurs sont utilisés pour appeler cette fonctionnalité, notamment lorsqu’une unité est enregistrée, lorsque l’onglet de l’éditeur change ou lorsqu’un fichier est modifié et n’est pas touché pendant un certain temps.

L’utilisation efficace de SORTA Compile nécessite un ajustement du flux de travail de codage, mais peut apporter d’énormes avantages au processus d’évolution de projet traditionnel en quatre étapes : modifier, compiler, exécuter, tester, répéter.

TwineCompile Trick #7 – Liaison statique ou dynamique

Si vous appliquez les astuces mentionnées ci-dessus à vos projets, vous constaterez probablement que vous commencerez à attendre l’éditeur de liens tout le temps. L’attente du compilateur disparaîtra complètement. C’est à la fois une bonne et une mauvaise chose. Bien parce qu’il

signifie que vous économisez tout ce temps, ce qui est dommage car vous ne pourrez pas faire grand-chose d’autre pour optimiser les performances de construction.

Cela dit, certaines applications peuvent être restructurées pour placer différentes fonctionnalités dans des DLL distinctes qui sont chargées par l’application au moment de l’exécution. Cela signifie que lorsque des modifications de code sont apportées à une certaine partie de l’application, seul ce code spécifique est compilé et lié dans son propre fichier DLL. Le reste de l’application n’a pas besoin d’être reconstruit car il est lié à cette DLL au moment de l’exécution.

De toute évidence, cette approche ajoute la surcharge de déploiement et de gestion des fichiers DLL supplémentaires qui doivent être regroupés avec l’application, mais les économies de performances de génération peuvent souvent valoir la surcharge supplémentaire.

Astuce #6 – Matériel

Notre dernière astuce est une astuce ancienne et bien connue, souvent appelée « jeter du matériel au problème ». Alors que le matériel plus récent et plus rapide dans le passé n’offrait que des avantages mineurs, les dernières avancées matérielles d’aujourd’hui, associées à la capacité de TwineCompile à maximiser l’utilisation des ressources système, peuvent offrir des avantages significatifs.

Il y a deux domaines clés sur lesquels il faut se concentrer :

1. Performances du disque

Cela signifie que les disques SSD utilisent des connexions NVMe/PCIe. Les SSD SATA sont bons, mais n’ont pas les performances d’accès aléatoire des SSD qui fonctionnent sur le bus PCIe.

Les broches sont un non-non définitif. Si vos projets, répertoires temporaires, système d’exploitation ou chemin d’installation de C++Builder se trouvent sur une broche, vos performances de construction seront épouvantables.

2. Cœurs de processeur

Les performances monocœur en ligne droite pour la compilation C++ sont moins utiles de nos jours que d’avoir plusieurs cœurs. Optez pour le nombre maximum de cœurs disponibles.

Les processeurs AMD Threadripper avec 64 cœurs (128 threads) sont idéaux pour la compilation C++ dans C++Builder avec TwineCompile. Notez que pour un processeur comme celui-ci, si vous avez moins de 128 fichiers C++ dans votre projet, vous gaspillez des ressources CPU. ressources en compilant de nombreux fichiers dans le même projet.

Dernières pensées

Nous avons parcouru un long chemin depuis l’époque de la compilation C++, lorsque les compilations prenaient beaucoup de temps et qu’il n’y avait rien à faire à ce sujet. Des outils et des techniques ont été développés qui font une différence significative pour les projets de toutes tailles. Nous en avons couvert un certain nombre dans cet article et nous espérons que vous pourrez les appliquer à vos propres projets pour rendre votre expérience de développement C++ plus rapide, plus simple et plus facile.

---

RAD Studio C++ Builder, pourquoi ne pas l’essayer aujourd’hui ?