2009-09-07 16 views
11

Abbiamo una soluzione di Visual Studio 2005 C++/Mfc di grandi dimensioni, 1 progetto con circa 1300 file di origine (quindi circa 650.h e 650 file .cpp). Usiamo anche Boost e alcune altre librerie (COM: MSXML, Office).Come aggirare il crash di Visual Studio Compiler

Recentemente, ho aggiunto alcune istanze di boost :: multi_index per velocizzare un po 'le cose. Tutto questo viene compilato per la maggior parte del tempo. Ma ora, quando eseguo una ricostruzione completa (rilascio), il compilatore si arresta in modo anomalo in alcuni moduli.

Fatal Error C1060: "compiler is out of heap space" 

ho già provato a ridurre include nel file di intestazione precompilata (rimosso praticamente tutto, tranne le intestazioni standard MFC). Inoltre, ho rimosso l'opzione del compilatore/Zm200 (che prima serviva per compilare il file di intestazione precompilato).

La cosa strana: quando premo F7 (build) dopo il crash del compilatore, il processo di compilazione continua senza problemi (o almeno fino al prossimo crash del compilatore, dove premo nuovamente F7). Ma sarebbe bello poter fare una compilazione completa senza pause.

Posso influenzare l'ordine di costruzione dei singoli moduli? In questo modo, potrei inserire i moduli "problematici" all'inizio del processo (e sperare che gli arresti non si spostino semplicemente su altri moduli).

BTW: una compilazione completa richiede circa 90 minuti.


Aggiornamento:

Grazie per le risposte. Sono stato in grado di sbarazzarsi del blocco del compilatore e ridurre significativamente il tempo di compilazione. Ecco cosa ho fatto:

  1. Ho rimosso tutti gli include dal file di intestazione precompilato, solo le intestazioni standard di windows/mfc sono rimaste come erano. Questo mi ha costretto ad aggiungere ancora più include in altri moduli, ma alla fine tutto è stato incluso dove era necessario. Ovviamente, questo passaggio ha aumentato il tempo di compilazione, ma mi ha permesso di essere più efficiente nel passaggio successivo.
  2. Ho installato la versione di prova di ProFactors IncludeManager. La Vista dettagli progetto può essere esportata in Excel, dove i colli di bottiglia e i candidati da includere nel file di intestazione precompilata possono essere individuati abbastanza velocemente.
  3. La maggior parte del tempo di compilazione è stato sprecato con alcuni file di intestazione che includevano un mucchio di altri file di intestazione (che includevano alcuni altri ...). Ho dovuto usare le dichiarazioni in avanti per sbarazzarmi di alcune brutte dipendenze. Inoltre, ho spostato alcune classi/funzioni da intestazioni critiche nei propri moduli.
  4. What to put in precompiled header? (MSVC) mi ha aiutato a ottenere gli include nel file di intestazione precompilato a destra. Ho aggiunto intestazioni STL, Boost, Windows. poi aggiunto le nostre intestazioni (più o meno stabili, ottimizzate), oltre al file di intestazione della risorsa.
  5. Ho ripetuto i passaggi 3 e 4 alcune volte, verificando sempre con IncludeManager per i nuovi candidati.
  6. I passaggi da 1 a 5 hanno portato il tempo di compilazione (modalità di rilascio) inattivo, da 90 a circa 45 minuti.
  7. Ho disabilitato la generazione di informazioni di ricerca per tutto, dal momento che non sembra utilizzarlo (e non sono riuscito a trovare alcuna informazione per quello che è veramente buono per ...). Questo ha tagliato altri 6 minuti del processo di costruzione.
  8. Ho aggiunto il comando/MP (multiprocessore) al comando del compilatore C++. Ora il tempo di ricostruzione è stato ridotto a 22 minuti. Tutto ciò è stato fatto su un PC single core.
  9. Ho spostato l'intera soluzione su un PC dual core. La ricostruzione del progetto dura 16 minuti lì.
  10. Creazione di una build di debug è 5 minuti più veloce:
    • 17 minuti sulla macchina single core,
    • 11 minuti sulla macchina dual core.

Aggiornamento 2:

Sopra, dove ho detto "macchina single core", in realtà una macchina dual core più lento si intende.

+0

'Sopra, dove menziono la" macchina single core ", si intende in realtà una macchina dual core più lenta. Lol –

risposta

3

Se 1300 file impiegano così tanto tempo per essere compilati, si includono waaaay troppi file di intestazione che non sono necessari. Immagino che le persone abbiano tagliato e incollato un gruppo di file di testo in un file CPP senza pensare a quali intestazioni effettivamente hanno bisogno in modo che molti di essi vengano inclusi quando non dovrebbero esserlo. Immagino anche che tu non sia avanti dichiarando classi dove dovresti essere.

Ti suggerisco di dedicare del tempo a passare il tuo progetto e rimuovere gli #inclusi non necessari. Sospetto che questo risolverà i tuoi problemi di memoria E migliorerà il tuo tempo di compilazione.

+0

sì, ci sono molte inclusioni nel progetto e sto cercando di ridurle anche. C'è uno strumento che può aiutarmi a identificare i moduli "critici" (quelli che includono la maggior parte degli altri)? – ToastedSoul

+1

prova Doxygen (http://www.stack.nl/~dimitri/doxygen/). Citando dal suo manuale: # Un grafico di dipendenza include viene generato per ogni file documentato che include almeno un altro file. Questa funzione è attualmente supportata solo per HTML e RTF. # Viene generato anche un grafico di dipendenza include inverso che mostra per un file (di intestazione), che altri file lo includono. Assicurati solo che il file di configurazione di Doxygen (chiamato Doxyfile) * non * abbia HIDE_UNDOC_RELATIONS impostato in modo da ottenere l'output per tutte le classi/elementi. – LaszloG

1

Dovrei essere d'accordo con Goz, dare un'occhiata a this (SO) post per vedere come rimuovere i file di intestazione ridondanti.

La nostra soluzione C++ è di queste dimensioni approssimative e utilizzata per impiegarci 50 minuti per la compilazione, mediante un'attenta analisi dei file di intestazione, che abbiamo ottenuto fino a 8 minuti.

+0

Grazie. Ho anche installato ProManager IncludeManager. Ora come posso identificare i moduli più critici? C'è un metodo suggerito? – ToastedSoul

+0

È passato un po 'di tempo da quando ci siamo arrabbiati, ma penso che abbiamo iniziato osservando l'inclusione del progetto e la struttura dei dettagli del progetto e cercando di vedere se c'era qualcosa di evidentemente sbagliato (incluso inaspettatamente), quindi siamo passati al tasto i file che sapevamo richiedevano molto tempo per compilare e guardare l'Impatto di costruzione su quelli. Penso che una volta risolto ciò che dovrebbe e non dovrebbe essere in stdafx.h, ciò ha fatto la differenza. In realtà potresti voler includere di più in stdafx.h se è incluso in molti file e quindi richiede molto tempo per essere compilato. –

0

IncrediBuild (sistema di generazione distribuito per VC++) oltre al risparmio di tempo ha un'ulteriore funzione utile. Riavvia automaticamente una compilazione se la macchina remota non riesce a restituire i risultati. Quindi dovresti essere in grado di ottenere build complete, senza arresti anomali in 5 o forse 10 minuti.

Problemi correlati