Riesige lib-Datei?

[FlorianB82]

Ich habe gerade meine gesamte Codebase (ca. 20K LOC / ohne Whitespace & Kommentare) in eine statische mutlithreaded Lib gesteckt, die ich einmal im Debug- und einmal in Release-Modus erstelle. Boost ist auch noch mit drin, aber nur in form von nen paar verwendeten Headers, keine Kompilate. Im Debug-Modus wird die erzeugte Lib ein wenig mehr als 20 MB groß, im Release-Modus 50 MB. Muss das so? Oder mache ich etwas falsch?

Auf Stackoverflow lese ich, dass man die "Whole Program Optimization" ausschalten solle, dann würde es signifikant kleiner. Aber das bedeutet doch dann auch, dass mir diese Optimierung für mein Endkompilat durch die Lappen geht, oder?

(Ja, mir ist bewusst, dass sich das für die Weitergabe aufgrund der statisch gelinkten CRT nur bedingt eignet. Aber die lib ist im Wesentlichen für mich bzw. für jeden Bibliotheksbenutzer zum Neukomplilieren, dann sollte das ja kein Problem sein? Es hängen ca nen halbes Duzend Programme mit im Projekt, die die Lib verwenden. Und so spare ich mir viel Heckmeck beim Compilieren, einfach Lib dazulinken, fertig.)

Greetz, Flo

[dot]

Ich habe gerade meine gesamte Codebase (ca. 20K LOC / ohne Whitespace & Kommentare) in eine statische mutlithreaded Lib gesteckt, die ich einmal im Debug- und einmal in Release-Modus erstelle. Boost ist auch noch mit drin, aber nur in form von nen paar verwendeten Headers, keine Kompilate. Im Debug-Modus wird die erzeugte Lib ein wenig mehr als 20 MB groß, im Release-Modus 50 MB. Muss das so? Oder mache ich etwas falsch?

Prinzipiell klingt das eigentlich nicht so falsch. Mich wundert nur, dass der Release Build größer ist als Debug. Oder hast du da was verwechselt? ;)
Was genau ist denn das Problem mit der Größe

(Ja, mir ist bewusst, dass sich das für die Weitergabe aufgrund der statisch gelinkten CRT nur bedingt eignet. Aber die lib ist im Wesentlichen für mich bzw. für jeden Bibliotheksbenutzer zum Neukomplilieren, dann sollte das ja kein Problem sein? Es hängen ca nen halbes Duzend Programme mit im Projekt, die die Lib verwenden. Und so spare ich mir viel Heckmeck beim Compilieren, einfach Lib dazulinken, fertig.)

Ist mir nicht ganz klar, was du damit sagen willst. Normalerweise fängt das ganze Heckmeck doch überhaupt erst damit an, dass man die CRT statisch linked!?

[FlorianB82]

Was genau ist denn das Problem mit der Größe

Kein konkretes. Mich hat es einfach nur gewundert, dass das so groß wird. Hätte ja sein können, dass ich irgendeine recht unpassende Option ausgewählt/nicht ausgewählt habe.

Mich wundert nur, dass der Release Build größer ist als Debug

Das ist wohl so, zumindest den Posts auf Stackoverflow nach zu urteilen. Angeblich liegts an der Whole Program Optimization. Und die ist bei mir im Debug Build aus, aber im Release natürlich an.

Ist mir nicht ganz klar, was du damit sagen willst. Normalerweise fängt das ganze Heckmeck doch überhaupt erst damit an, dass man die CRT statisch linked!?

Richtig. Deswegen meinte ich ja auch, dass ich diese Lib nicht als Auslieferungseinheit verwende. Das ganze wird eh komplett Quelloffen, da kann sich jeder die Lib gemäss seinen Anforderungen zusammenkonfigurieren, bevor er den Rest (=Anwendungen, die die Lib nutzen) kompiliert.
Es sind halt einfach ein paar Programme, die die Lib verwenden, mit drin. Und für die habe ich das gemacht. Ich hatte einfach keinen Bock, im Visual Studio riesige Ordner mit den Headern und Implementationen zu haben, noch dazu in X-facher Ausführung. So habe ich nur die Header/Cpps der jeweiligen Anwendung drin, und linke zur Lib. Kompiliert insgesamt auch schneller: Lib erstellen braucht ne Weile, aber das Erstellen der Anwendungen geht dann ratz fatz.

Oder ist das jetzt total beknackt organisiert? Ich fand es vorher halt recht nervig.

[Krishty]

Whole Program Optimization und Link Time Code Generation ermöglichen dem Compiler, über Modulgrenzen hinweg zu optimieren. (Beispielsweise kann er nur dann Funktionen inlinen, die in einem anderen Modul definiert sind als ihr Aufrufer – und noch bedeutend mehr).

Dafür wird aber vorausgesetzt, dass beim Linker kein fertiger Maschinentext ankommt, sondern dass der Compiler bloß in eine Zwischensprache übersetzt, so dass die Quellstruktur erhalten bleibt, bis das Programm im Linker ankommt.

Darum ist die Lib so groß: Sie enthält keinen fertigen Maschinentext, sondern alles, was je irgendwo irgendwann in deinem Quelltext definiert wurde, in einer symbolischen Zwischensprache (plus Zusatzinformationen um bspw. Fehler vom Linker aus zum dazugehörigen Quelltext zurückverfolgen zu können).

Also ganz normal. Und Whole Program Optimization bringt eine Menge, also lass sie an, falls nicht andere Faktoren dagegensprechen.

Gruß, Ky