Quelle est la taille raisonnable d'un fichier PDB Visual C++ ?

Question

Je travaille à la réduction du temps de construction d'une grande application Visual C++ 2008. L'un des goulets d'étranglement les plus importants semble être la génération du fichier PDB : au cours de l'étape de liaison, mspdbsrv.exe consomme rapidement la RAM disponible, et la machine de construction commence à paginer constamment.

Ma théorie actuelle est que nos fichiers PDB sont tout simplement trop volumineux. Cependant, je n'ai pu trouver aucune information sur la taille "normale" d'un fichier PDB. J'ai pris quelques mesures approximatives de l'une des DLL de notre application, comme suit :

• Fichiers CPP : 34.5 MB, 900k lignes
• Fichiers d'en-tête : 21 MB, 400k lignes
• DLL compilée : 33 MB (compilée pour le débogage, pas pour la version release)
• PDB : 187 MB

Le fichier PDB représente donc environ 570 % de la taille de la DLL. Quelqu'un ayant l'expérience des grandes applications Visual C++ peut-il me dire si ces ratios et ces tailles ont un sens ? Ou y a-t-il là un signe que nous faisons quelque chose de mal ?

(Le fichier PDB le plus volumineux dans notre application est actuellement de 271 Mo, pour une DLL de 47,5 Mo. La taille du code source est cependant plus difficile à mesurer).

Merci de votre attention !

Answer 1

Oui, les fichiers .pdb peuvent être très volumineux, y compris les tailles que vous mentionnez. Étant donné qu'un fichier .pdb contient des données permettant de faire correspondre les lignes de source au code machine et que vous compilez beaucoup de code, le fichier .pdb contient beaucoup de données et vous ne pouvez probablement rien en faire directement.

Vous pouvez essayer de diviser votre programme en plusieurs parties, les DLL. Chaque DLL aura son propre fichier .pdb indépendant. Cependant, je doute sérieusement que cela réduise le temps de construction.

Answer 2

Avez-vous vraiment besoin d'informations de débogage complètes à tout moment ? Vous pouvez créer une configuration avec moins d'informations de débogage.

Mais comme l'a déjà dit sharptooth, il est temps de refactoriser et de diviser votre programme en petites parties plus faciles à maintenir. Cela ne réduira pas seulement le temps de construction.