Kompilatgröße

[Gast]

Hallo zusammen,

ich hatte bisher noch auf Visual Studio Prof. 2005 gesetzt und bin nun auf die 2008er Version umgestiegen. Beim ersten Start eines 2005er Projekts in VS 2008 kommt ja dieser Assistent zum Konvertieren der Projekt-Einstellungen. Das klappte soweit auch gut und die Einstellungen im 2008er sind haargenau so wie vorher im 2005er.
Bei einem meiner Projekte wird eine DLL erstellt. Mit VS 2005 hatte diese ~1.2MB, nun sind es 1,3MB mit VS 2008. Woran kann das liegen? :)

[Ectoplasma]

Der Unterschied ist so gering, dass man darüber eigentlich kaum diskutieren kann. Aber ich schätze, dass es an der STL liegen könnte, falls diese verwendet wird.

[Spike2]

Wird mit 2010 noch fetter :) Im offiziellen eMule-Forum gab es schon eine Diskussion darüber, da eMule ja auch noch auf VS.2003SP1 setzt (die offizielle Version), aber viele Modder inzwischen auf 2005, 2008 oder gar schon 2010 umgestiegen sind.

Gründe sind auch dort nicht bekannt, nur daß bei jemandem die emule.exe sogar um 1.5 MB gewachsen ist...

Also 2005: +/- 0
2008: +150 kb
2010: +1,5 MB (!)

[Monger]

Ach du scheiße! 1,5MB !!! Wie soll ich das nur auf meine Festplatte kriegen? :ugly:

Es gibt ein paar Sachen, die in den Projekten bei VS 2008 und 2010 dazugekommen sind, wie z.B. das Vista Manifest. Wahrscheinlich steckt jetzt ganz allgemein n bissl mehr Metainformation zwecks Rechtemanagement drin. Eventuell arbeitet auch der Resourcenkompiler etwas anders, ich weiß z.B. dass der unter .NET ab 2008 ein paar Optionen mehr hatte.

Aber in den Bereichen sich über die Größe aufzuregen, ist sowieso witzlos. Wenn dein 30MB plötzlich 60MB groß ist, DANN würde ich mir Gedanken machen.

[Nighthawk13]

Setzt mal explizit das Optimierungsflag /O2 im Release-Build bei allen Projects(so das es fett gedruckt ist in den Einstellungen).
Kenne das Problem, dass nach dem Projekt-Konvertieren zu 2005->2008 die GUI zwar O2 anzeigt, der Compiler aber ohne Optimierung baut und die .exe grösser(und vor allem langsamer) wird.

[Krishty]

Warte erst, bis du die DLL für x64 kompilierst ;)

Wenn die Größe eh gerade ein Thema ist, schau mal nach, ob auch String-Pooling und COMDAT-Folding aktiviert sind (mit voller Optimierung (/Ox) immer) … die können hier und da ein Bisschen (und bei vielen Strings/Templates auch ein bisschen mehr) rausholen …

Pro Compiler-Umstieg ein bisschen mehr Größe ist normal – bedingt z.B. durch immer weiter verbesserte Run-Time-Checks (/GS-Flag) und neue Optimierungen (insbesondere SSE wird von Version zu Version massiver eingesetzt. Das sorgt für bessere Performance, aber kann auch Platz fressen).

Achja: Wenn es um die Optimierung geht, wirkt Function-Level-Linking mit LTCG wahre Wunder, fordert dafür aber auch deutlich mehr Kompilierzeit.

[Coda]

LTCG ist doch mindestens seit 2008 eh standard.

[Krishty]

Bei importierten 2005er-Projekten auch?