2012-07-12 10 views
10

Abbiamo un grande progetto,> 1M di codice in circa 300 DLL. Finora abbiamo utilizzato VS6.Enormi file OBJ nella compilazione C++ VS2008 rispetto a VS6

Ora ho convertito tutto in VS2008, tutte le compilazioni, i collegamenti e, cosa più importante, corre!

==> Tuttavia ... i file OBJ compilati risultanti sono X 10 più grandi e il collegamento è estremamente lento, con il linker che colpisce spesso> 1 GB di memoria.

Parte delle implicazioni sono che ho bisogno di compilare determinati progetti con/bigobj.

Il risultato è una build che è passata da circa 1:45 su un desktop a 3 ore. Le DLL e le LIB hanno approssimativamente le stesse dimensioni del vecchio build VS6.

Ho letto tutto quello che ho trovato qui ma non ho trovato un rimedio a questo problema. Se si tratta di informazioni aggiuntive su DEBUG, non lo voglio. Ne avevo abbastanza prima. La dimensione in uscita è aumentata, ma non così tanto ...

Qualcuno ha qualche idea? O è la mia unica opzione per abbattere i progetti in unità molto più piccole? Ristrutturare la mia unica speranza ?! Sicuramente c'è una bandiera segreto mi mancava ...


Edit1 (13/07/2012 12: 20BST) Ho confrontato dumpbin di un Obj creato da VS6 vs. VS2008. Quello nel 2008 appare come come "collegamento statico". In VS6 contiene alcuni simboli tutti dalla DLL corrente. In VS2008 contiene simboli da (probabilmente) tutte le librerie da cui dipende. Le dimensioni del dumpbin sono 66kb e 32,000kb per VS6 e VS2008, rispettivamente.


+2

Provare a disabilitare "informazioni di debug" nelle impostazioni del progetto (ramo C++). –

+7

_ "Abbiamo un grande progetto,> 1 milione di righe di codice in circa 300 DLL. Finora abbiamo utilizzato VS6." _ Non mi lamenterò più del mio lavoro. – Luke

+0

@IvanShcherbakov: questo non mi impedisce di eseguire facilmente il debug? – aabramovich

risposta

5

Controlla le opzioni di debug. /Z7 causa file .OBJ di grandi dimensioni, /Zi inserisce le stesse informazioni in un file .PDB separato.

L'opzione del compilatore /Oi può essere d'aiuto mediante l'inlining della funzione intrinseca, che non deve più essere collegata. Probabilmente non vuoi eseguire il debug di memset.

Spegnere /Gm (ricostruzione incrementale) in modo da poter attivare /MP (versione parallela). Spegni anche /Gy - mentre fa per piccoli EXE, causa file OBJ più grandi e collegamenti più lenti.

+0

Grazie a @MSalters, usiamo/ZI, usiamo/MP, e GY è disattivato.Ho anche giocato con il collegamento incrementale e non incrementale.Non incrementale è doloroso Molto Adding/Oi ora - riporterà in 12h – aabramovich

+0

Il collegamento incrementale ha esaurito la memoria e non riesco a trovare un modo per aggirarlo.la dimensione dell'oggetto si è ridotta di circa il 25%, ma sono ancora enormi.Non posso usare il flag/3GB come molti gli sviluppatori (erm) usano computer portatili con 3 GB complessivi ... Proverò a cambiare OS, poiché ho XP ... – aabramovich

+1

La bandiera '/ 3GB' si riferisce alla a spazio di ddress per l'eseguibile creato e non ha alcun effetto sul compilatore o sul linker stesso. Inoltre, questo è lo spazio degli indirizzi da 3 GB, che include file mappati in memoria, non RAM. – MSalters

Problemi correlati