MSVC2005 : Compilation d'un .lib donne 1Go

Version imprimable

14/08/2008, 14h54
mister3957

MSVC2005 : Compilation d'un .lib donne 1Go

Bonjour à tous,

J'ai une librairie statique d'utilitaire qui possède une dizaine de classe, après compilation j'obtient un fichier .lib de 10mo

J'ai une seconde librairie statique de gestion qui utilise la première et qui possède une 10/15 classes, le .lib fait également 10mo

Par contre, j'ai une troisième librairie statique qui utilise la seconde, qui elle possède 55 classes métiers, le .lib généré fait près d'1Go.. 963Mo plus exactement.

Du coup je me retrouve souvent avec des erreurs de link

Citation:

fatal error LNK1106: fichier non valide ou disque plein*: impossible de rechercher sur 0x2E9D3B9F

Dans les options de compilation, j'ai laissé par défaut en Release.

Est-ce que ça peut être le fait que toutes mes classes de la troisième librairie héritent de classes template de la seconde ? Pour une classe métier, le compilateur va générer 3 classes supplémentaires.
Mais ça fait 4 * 55 = 220 classes, qui sont en générale assez petite, ça fait beaucoup 1Go pour ça nan ?

J'utilise également une hiérarchie éparpillée qui va faire dériver une classe de mes 55 classes métiers + une classe de singleton.

Je peux faire quelque chose ?

Merci,

A bientôt
14/08/2008, 16h47
Spout

Ajoutes-tu d'autres librairies de manière statique à ton projet? Genre les MFC?
14/08/2008, 18h46
Sylvain Togni

Combien de lignes de code au total ? Parce que 1Go c'est énorme pour un .lib, ce n'est pas quelques centaines de classes qui vont générer un fichier aussi gros, sauf ci elles ont plusieurs millions de lignes de code chacune, si elles utilisent des grands tableaux statiques, ou si inline est utiliser à tout bout de champs.
15/08/2008, 02h16
Klaim

Déjà 10Mo pour une dixaine de classes, ça me parait énorme...

Ya l'utilisation massive de templates d'autres lib (par exemple boost) qui peut grossir ta lib, l'inclusion d'autres lib comme dit précédemment...

1Go... a mon avis ya un problème quelque part...
15/08/2008, 11h38
mister3957

J'ai essayé de retirer l'option /Zi, qui génère une base de donnée du programme. J'ai baissé de 100Mo à peut prêt et les deux p'tites lib de 1Mo

Sinon comme librairie, j'utilise xerces 2.8 seulement dans la troisième c'est tout.
J'ai pas mon projet sous les yeux là, mais dès que je reviens en France je vous détaillerai ce que j'ai.

J'essayerai également de faire un nouveau projet, relaisser tout par défaut, et intégrer mes classes voir si c'est pas moi qui ai modifié une option du compilateur par mégarde, mais bon, j'avais déjà créé un projet vide et m'étais basé dessus pour remettre toutes les options par défaut...

Merci :)
15/08/2008, 12h47
Klaim

Quel type de projet exactement?
17/08/2008, 14h25
mister3957

Comment ça quel type de projet ?

Console ? Win32 ? etc... ?
J'avais commencé en console, puis voyant ces 1Go, je suis passé en "subsystem:windows" et j'ai remplacé le main par un winmain, mais ça n'a rien changé.

Est-ce que c'est bien ça que tu me demandais ?

En tout cas merci :)

A bientôt
17/08/2008, 16h41
Klaim

Oui, normalement même en console si tu as selectionné "vide" (pas de source code au démarrage) tu ne devrais pas avoir le problème...
20/08/2008, 12h10
mister3957

Ayé j'ai trouvé mais c'est un peu space.

Si je retire l'option "/LTCG (Génération de code durant l'édition de liens)", ma librairie tombe à 26mo....
20/08/2008, 14h26
stephl

Citation:

Envoyé par mister3957

Ayé j'ai trouvé mais c'est un peu space.

Si je retire l'option "/LTCG (Génération de code durant l'édition de liens)", ma librairie tombe à 26mo....

Citation:

Envoyé par msdn

The /LTCG option tells the linker to call the compiler and perform whole program optimization.

Je me demande ce qu'ils ont bien pu optimiser pour faire passer la taille de la librairie de 26 Mo à 1 Go :?
20/08/2008, 14h30
mister3957

Bé ué :s
20/08/2008, 14h45
stephl

Personnellement, 26 Mo, je trouve cela encore très gros. Maintenant, je ne sais pas à quoi sert ta librairie.
20/08/2008, 14h50
mister3957

Y'a toute la gestion de mes données métiers avec ce qui va autour (connexion à plusieurs sources de données par exemple).
20/08/2008, 15h03
HanLee

Citation:

Envoyé par stephl

Je me demande ce qu'ils ont bien pu optimiser pour faire passer la taille de la librairie de 26 Mo à 1 Go :?

De l'inlining par exemple.
20/08/2008, 15h04
stephl

OK, merci. Je suppose que c'est ce qui doit expliquer la taille de la lib.
20/08/2008, 15h07
stephl

Citation:

Envoyé par HanLee

De l'inlining par exemple.

Oui, mais là pour le coup, ils ont dû inliner TOUTES les fonctions pour que cela fasse 1 Go!!! Je ne suis pas certain qu'on gagne en performance à tout inliner.
20/08/2008, 15h46
Klaim

Ca dépends ce qui est inliné en fait... il se peut que ça boost les perfs à l'execution mais le contraire aussi est possible...
Dans tous les cas, tu peux pas savoir sans tester la différence et a mon avis c'est pas une lib qui doit nécessiter des performances de taré.
20/08/2008, 22h51
JolyLoic

Citation:

Envoyé par stephl

Oui, mais là pour le coup, ils ont dû inliner TOUTES les fonctions pour que cela fasse 1 Go!!!

Il n'a pas forcément inliné quoi que ce soit. Cette option à pour objectif de permettre d'iniliner au moment où l'on créera le programme final. Au moment où la bibliothèque est créée, on ne sait pas encore quelle fonction sera inlinée ou pas à terme. Donc, on met dedans plein d'information pour permettre cet inlining au cas où. Schématiquement, on met tout le code source dans le .lib.

Que le résultat fasse 1Go me semble beaucoup.
20/08/2008, 23h27
mister3957

Nan y'a que quelques fonctions qui selon moi demande des perfs assez évoluées de par leur utilisation et leur complixité, mais le compilateur ne le sait pas.

Si ça peut vous aider, j'ai une soixantaine de classes qui via les templates en génère 3 chacune. Chacune de ces classe métier ne possède actuellement que des accesseurs.

Mais ouais 1Go pour ça.... avec les erreurs de link en prime, c'est un peu juste
21/08/2008, 00h52
Matthieu Brucher

Citation:

Envoyé par stephl

Je me demande ce qu'ils ont bien pu optimiser pour faire passer la taille de la librairie de 26 Mo à 1 Go :?

Dans ce fichier, il y a tout ce qui est nécessaire pour effectuer l'édition des liens... avec un exécutable ou une bibliothèque dynamique. Dans une bibliothèque statique, il n'y a en réalité aucune édition des liens d'effectuée.
21/08/2008, 14h48
stephl

Citation:

Envoyé par JolyLoic

Il n'a pas forcément inliné quoi que ce soit. Cette option à pour objectif de permettre d'iniliner au moment où l'on créera le programme final. Au moment où la bibliothèque est créée, on ne sait pas encore quelle fonction sera inlinée ou pas à terme. Donc, on met dedans plein d'information pour permettre cet inlining au cas où. Schématiquement, on met tout le code source dans le .lib.

Que le résultat fasse 1Go me semble beaucoup.

Si la lib contient en gros le code source, je trouve cela bizarre car je doute qu'il y ait 1 Go de sources... Même s'il y a 100 Mo de source (je pense être très généreux), ça fait 10 fois plus.
Et en ce qui concerne les templates, comme le code est généré à l'instanciation, je me demande si ce ne serait pas à ce moment là que le code est inliné (et éventuellement dupliqué).
21/08/2008, 14h54
stephl

Citation:

Envoyé par Matthieu Brucher

Dans ce fichier, il y a tout ce qui est nécessaire pour effectuer l'édition des liens... avec un exécutable ou une bibliothèque dynamique. Dans une bibliothèque statique, il n'y a en réalité aucune édition des liens d'effectuée.

Je suis d'accord avec toi et je ne crois pas avoir dit le contraire. Ce que je veux dire, c'est que c'est tout de même le linker qui se charge de construire la lib et que je pense qu'à ce moment, le compilateur a peut-être déjà inliné les fonctions présentes dans les headers et marquées inline, ainsi que les templates (compilés et éventuellement inlinés).
21/08/2008, 15h06
Matthieu Brucher

Citation:

Envoyé par stephl

Je suis d'accord avec toi et je ne crois pas avoir dit le contraire. Ce que je veux dire, c'est que c'est tout de même le linker qui se charge de construire la lib et que je pense qu'à ce moment, le compilateur a peut-être déjà inliné les fonctions présentes dans les headers et marquées inline, ainsi que les templates (compilés et éventuellement inlinés).

Effectivement, tu n'as pas dit le contraire ;) Si ça se trouve toutes les possibilités ont été générées par le compilateur et c'est l'éditeur des liens qui va, à la fin, choisir les meilleures solutions (potentiellement basées sur un profil), comme tu le dis.
Je pense aussi que pour une bibliothèque statique, avec les inconvénients qu'elle présente de manière générale, il vaut mieux ne pas prendre cette option. Les autres compilateurs ne peuvent pas tirer partie de ces données complémentaires.
21/08/2008, 15h17
stephl

Citation:

Envoyé par Matthieu Brucher

Effectivement, tu n'as pas dit le contraire ;) Si ça se trouve toutes les possibilités ont été générées par le compilateur et c'est l'éditeur des liens qui va, à la fin, choisir les meilleures solutions (potentiellement basées sur un profil), comme tu le dis.

Probablement. De toute façon, je ne m'y connais pas assez dans ce domaine pour m'avancer davantage. Je suis d'accord avec ton explication.

Citation:

Envoyé par Matthieu Brucher

Je pense aussi que pour une bibliothèque statique, avec les inconvénients qu'elle présente de manière générale, il vaut mieux ne pas prendre cette option. Les autres compilateurs ne peuvent pas tirer partie de ces données complémentaires.

J'ai effectivement lu cela. Et même sans prendre en compte cette option, le code généré par un compilateur C++ (que ce soit un obj, une lib ou une dll) peut poser des problèmes si utilisé avec un compilateur/linker différent ou même avec le même compilateur et des options de compilation différentes. Ces incompatibilités peuvent être dues au name mangling, au layout des classes en mémoire, à la gestion des exceptions et j'en passe...