Tempi di compilazione molto lenti su Visual Studio 2005

https://stackoverflow.com/questions/55517

09-06-2019
|

Domanda

Stiamo riscontrando tempi di compilazione molto lenti, che possono richiedere fino a 20+ minuti su macchine dual core da 2GHz, 2G Ram.

Gran parte di ciò è dovuto alle dimensioni della nostra soluzione che è cresciuta fino a raggiungere oltre 70 progetti, nonché a VSS che costituisce di per sé un collo di bottiglia quando si hanno molti file.(scambiare VSS non è un'opzione sfortunatamente, quindi non voglio che questo diventi un bash VSS)

Stiamo valutando progetti di fusione.Stiamo anche cercando di avere più soluzioni per ottenere una maggiore separazione delle preoccupazioni e tempi di compilazione più rapidi per ciascun elemento dell'applicazione.Posso vedere che diventerà un inferno di DLL mentre cerchiamo di mantenere le cose sincronizzate.

Sono interessato a sapere come altri team hanno affrontato questo problema di ridimensionamento, cosa fai quando la tua base di codice raggiunge una massa critica che stai sprecando metà giornata a guardare la barra di stato fornire messaggi di compilazione.

AGGIORNAMENTOHo trascurato di menzionare che questa è una soluzione C#.Grazie per tutti i suggerimenti C++, ma è da qualche anno che non mi devo preoccupare delle intestazioni.

MODIFICARE:

Suggerimenti carini che hanno aiutato finora (non sto dicendo che non ci siano altri suggerimenti carini di seguito, solo quelli che hanno aiutato)

Nuovo laptop da 3 GHz: la potenza della perdita di utilizzo fa miracoli quando si lamenta il management
Disattiva l'antivirus durante la compilazione
"Disconnessione" da VSS (in realtà la rete) durante la compilazione: potrei convincerci a rimuovere del tutto l'integrazione VS-VSS e continuare a utilizzare l'interfaccia utente VSS

Ancora non riesco a sniffare una compilazione, ma ogni cosa aiuta.

Orion ha menzionato in un commento che anche i generici potrebbero avere un ruolo.Dai miei test sembra esserci un calo minimo delle prestazioni, ma non abbastanza elevato per essere sicuro: i tempi di compilazione possono essere incoerenti a causa dell'attività del disco.A causa dei limiti di tempo, i miei test non includevano tanti generici o tanto codice quanto apparirebbero nel sistema live, quindi potrebbero accumularsi.Non eviterei di utilizzare generici dove dovrebbero essere utilizzati, solo per le prestazioni in fase di compilazione

SOLUZIONE

Stiamo testando la pratica di costruire nuove aree dell'applicazione in nuove soluzioni, importando le DLL più recenti come richiesto, integrandole nella soluzione più ampia quando ne siamo soddisfatti.

Potremmo anche fare lo stesso con il codice esistente creando soluzioni temporanee che incapsulano semplicemente le aree su cui dobbiamo lavorare e buttandole via dopo aver reintegrato il codice.Dobbiamo valutare il tempo necessario per reintegrare questo codice rispetto al tempo che guadagneremo non avendo esperienze come Rip Van Winkle con ricompilazione rapida durante lo sviluppo.

Soluzione

Il team di Chromium.org ha elencato diverse opzioni per accelerando la costruzione (a questo punto circa a metà pagina):

In ordine decrescente di accelerazione:

Installa l'aggiornamento rapido Microsoft 935225.

Installa l'aggiornamento rapido Microsoft 947315.

Utilizzare un vero processore multicore (es.un Intel Core Duo 2;non un Pentium 4 HT).

Utilizza 3 build parallele.In Visual Studio 2005 troverai l'opzione in Strumenti > Opzioni...> Progetti e soluzioni > Compila ed esegui > numero massimo di build di progetti paralleli.

Disattiva il software antivirus per i file .ilk, .pdb, .cc, .h e controlla la presenza di virus solo su modificare.Disabilita la scansione della directory in cui risiedono le tue fonti.Non fare niente di stupido.

Archivia e crea il codice Chromium su un secondo disco rigido.Non accelererà davvero la build, ma almeno il tuo computer rimarrà reattivo quando esegui la sincronizzazione con gclient o una build.

Deframmenta regolarmente il tuo disco rigido.

Disabilita la memoria virtuale.

Altri suggerimenti

Abbiamo quasi 100 progetti in un'unica soluzione e un tempo di creazione di sviluppo di pochi secondi :)

Per le build di sviluppo locale abbiamo creato un componente aggiuntivo di Visual Studio che cambia Project references A DLL references e scarica i progetti indesiderati (e un'opzione per ripristinarli ovviamente).

Costruisci la nostra intera soluzione una volta
Scarica i progetti su cui non stiamo attualmente lavorando e modifica tutti i riferimenti al progetto in riferimenti DLL.
Prima del check-in, ripristina tutti i riferimenti da DLL a riferimenti al progetto.

Le nostre build ora richiedono solo pochi secondi quando lavoriamo solo su pochi progetti alla volta.Possiamo anche eseguire il debug dei progetti aggiuntivi poiché si collega alle DLL di debug.Lo strumento impiega in genere 10-30 secondi per apportare un gran numero di modifiche, ma non è necessario farlo così spesso.

Aggiornamento maggio 2015

L'accordo che ho fatto (nei commenti qui sotto) era che avrei rilasciato il plugin su Open Source Se suscita abbastanza interesse.4 anni dopo ha solo 44 voti (e Visual Studio ora ha due versioni successive), quindi è attualmente un progetto a bassa priorità.

Ho riscontrato un problema simile su una soluzione con 21 progetti e 1/2 milione di LOC.La differenza più grande è stata ottenere dischi rigidi più veloci.Dal monitoraggio delle prestazioni l''Avg.Disk Queue' saltava in modo significativo sul laptop indicando che il disco rigido era il collo di bottiglia.

Ecco alcuni dati per i tempi di ricostruzione totali...

1) Laptop, unità Core 2 Duo da 2 GHz, 5400 RPM (non sono sicuro della cache.Era Dell Inspiron standard).

Tempo di ricostruzione = 112 secondi.

2) Desktop (edizione standard), Core 2 Duo da 2,3 Ghz, unità singola da 7.200 giri/min, cache da 8 MB.

Tempo di ricostruzione = 72 secondi.

3) Desktop Core 2 Duo 3Ghz, singolo WD Raptor da 10.000 giri/min

Tempo di ricostruzione = 39 secondi.

L'unità da 10.000 RPM non può essere sottovalutata.Le build sono state significativamente più veloci, oltre a tutto il resto come la visualizzazione della documentazione, l'utilizzo di Esplora file è stato notevolmente più rapido.È stato un grande aumento della produttività accelerando il ciclo di creazione-esecuzione del codice.

Considerato ciò che le aziende spendono per gli stipendi degli sviluppatori, lo è pazzo quanto possono sprecare acquistando dotandoli degli stessi PC utilizzati dalla receptionist.

Per le build C# .NET è possibile utilizzare Demone .NET.È un prodotto che riprende il processo di compilazione di Visual Studio per renderlo più veloce.

Lo fa analizzando le modifiche apportate e crea solo il progetto effettivamente modificato, nonché altri progetti che si basavano effettivamente sulle modifiche apportate.Ciò significa che se modifichi solo il codice interno, è necessario creare un solo progetto.

Disattiva l'antivirus.Aggiunge età al tempo di compilazione.

Utilizzare la compilazione distribuita.Xoreax IncrediBuild può ridurre il tempo di compilazione a pochi minuti.

L'ho usato su un'enorme soluzione C\C++ che di solito richiede 5-6 ore per essere compilata.IncrediBuild ha contribuito a ridurre questo tempo a 15 minuti.

Istruzioni per ridurre il tempo di compilazione di Visual Studio a pochi secondi

Sfortunatamente Visual Studio non è abbastanza intelligente da distinguere le modifiche dell'interfaccia di un assembly dalle modifiche irrilevanti del corpo del codice.Questo fatto, se combinato con ampie soluzioni intrecciate, a volte può creare una tempesta perfetta di "build complete" indesiderate quasi ogni volta che si modifica una singola riga di codice.

Una strategia per superare questo problema è disabilitare la creazione automatica dell'albero di riferimento.Per fare ciò, utilizzare il "Gestione configurazione" (Build/Gestione configurazione... quindi nel menu a discesa Configurazione della soluzione attiva, scegliere "Nuovo") per creare una nuova configurazione di build denominata "ManualCompile" che copia dalla configurazione di debug, ma non non selezionare la casella di controllo "Crea nuove configurazioni di progetto".In questa nuova configurazione di build, deseleziona ogni progetto in modo che nessuno di essi venga creato automaticamente.Salva questa configurazione premendo "Chiudi".Questa nuova configurazione di build viene aggiunta al file della soluzione.

Puoi passare da una configurazione di build a un'altra tramite il menu a discesa della configurazione di build nella parte superiore della schermata IDE (quella che di solito mostra "Debug" o "Release").In effetti questa nuova configurazione di build ManualCompile renderà inutili le opzioni del menu Build per:"Crea soluzione" o "Ricostruisci soluzione".Pertanto, quando sei in modalità ManualCompile, devi creare manualmente ogni progetto che stai modificando, operazione che può essere eseguita facendo clic con il pulsante destro del mouse su ciascun progetto interessato in Esplora soluzioni e quindi selezionando "Crea" o "Ricostruisci".Dovresti vedere che i tempi di compilazione complessivi saranno ora di pochi secondi.

Affinché questa strategia funzioni, è necessario che il VersionNumber trovato nei file AssemblyInfo e GlobalAssemblyInfo rimanga statico sul computer dello sviluppatore (non durante le build di rilascio ovviamente) e che tu non firmi le tue DLL.

Un potenziale rischio derivante dall'utilizzo di questa strategia ManualCompile è che lo sviluppatore potrebbe dimenticare di compilare i progetti richiesti e, quando avvia il debugger, ottiene risultati imprevisti (impossibile collegare il debugger, file non trovati, ecc.).Per evitare ciò, probabilmente è meglio utilizzare la configurazione di build "Debug" per compilare uno sforzo di codifica più ampio e utilizzare solo la configurazione di build ManualCompile durante i test unitari o per apportare modifiche rapide di portata limitata.

Se si tratta di C o C++ e non stai utilizzando intestazioni precompilate, dovresti esserlo.

Avevamo più di 80 progetti nella nostra soluzione principale la cui realizzazione richiedeva dai 4 ai 6 minuti a seconda del tipo di macchina su cui stava lavorando lo sviluppatore.Abbiamo ritenuto che fosse troppo lungo:per ogni singolo test divora davvero i tuoi FTE.

Quindi, come ottenere tempi di costruzione più rapidi?Come sembra che tu già sappia, è il numero di progetti che danneggia davvero il tempo di costruzione.Naturalmente non volevamo sbarazzarci di tutti i nostri progetti e semplicemente mettere tutti i file sorgente in uno solo.Ma avevamo alcuni progetti che potevamo comunque combinare:Poiché ogni "progetto repository" nella soluzione aveva il proprio progetto unittest, abbiamo semplicemente combinato tutti i progetti unittest in un unico progetto unittest globale.Ciò ha ridotto il numero di progetti con circa 12 progetti e in qualche modo ha risparmiato il 40% del tempo per costruire l'intera soluzione.

Stiamo pensando però ad un'altra soluzione.

Hai anche provato a impostare una nuova (seconda) soluzione con un nuovo progetto?Questa seconda soluzione dovrebbe semplicemente incorporare tutti i file utilizzando le cartelle della soluzione.Perché potresti rimanere sorpreso nel vedere i tempi di realizzazione di quella nuova soluzione con un solo progetto.

Tuttavia, lavorare con due soluzioni diverse richiederà un’attenta considerazione.Gli sviluppatori potrebbero essere propensi a lavorare effettivamente con la seconda soluzione e trascurare completamente la prima.Poiché la prima soluzione con oltre 70 progetti sarà la soluzione che si prenderà cura della tua gerarchia di oggetti, questa dovrebbe essere la soluzione in cui il tuo buildserver dovrebbe eseguire tutti i tuoi unittest.Quindi il server per la Continuation Integration deve essere il primo progetto/soluzione.Devi mantenere la tua gerarchia di oggetti, giusto.

La seconda soluzione con un solo progetto (che verrà creato molto più velocemente) sarà il progetto in cui test e debug verranno eseguiti da tutti gli sviluppatori.Devi prenderti cura di loro guardando il buildserver però!Se qualcosa si rompe DEVE essere riparato.

Assicurati che i tuoi riferimenti siano riferimenti al progetto e non direttamente alle DLL nelle directory di output della libreria.

Inoltre, impostali per non copiare localmente tranne dove assolutamente necessario (il progetto EXE master).

Originariamente ho postato questa risposta qui:https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473Puoi trovare molti altri suggerimenti utili in quella pagina.

Se utilizzi Visual Studio 2008, puoi compilare utilizzando il flag /MP per creare un singolo progetto in parallelo.Ho letto che anche questa è una funzionalità non documentata in Visual Studio 2005, ma non l'ho mai provata personalmente.

Puoi creare più progetti in parallelo utilizzando il flag /M, ma di solito è già impostato sul numero di core disponibili sulla macchina, anche se credo che si applichi solo a VC++.

Noto che questa domanda è vecchia di secoli, ma l'argomento è ancora interessante oggi.Lo stesso problema mi ha tormentato ultimamente e le due cose che hanno migliorato maggiormente le prestazioni di compilazione sono state (1) utilizzare un disco dedicato (e veloce) per la compilazione e (2) utilizzare la stessa cartella di output per tutti i progetti e impostare CopyLocal su False sul progetto Riferimenti.

Alcune risorse aggiuntive:

Alcuni strumenti di analisi:

Strumenti-> Opzioni-> Impostazioni del progetto VC ++-> Build Timing = Sì ti dirà di creare tempo per ogni VCProj.

Aggiungere /Bt passa alla riga di comando del compilatore per vedere quanto ha impiegato ogni file CPP

Utilizzo /showIncludes per catturare include annidate (file di intestazione che includono altri file di intestazione) e vedere quali file potrebbero risparmiare molto I/O utilizzando le dichiarazioni in avanti.

Ciò ti aiuterà a ottimizzare le prestazioni del compilatore eliminando le dipendenze e i problemi di prestazioni.

Prima di spendere soldi per investire in dischi rigidi più veloci, prova a creare il tuo progetto interamente su un disco RAM (supponendo che tu abbia abbastanza RAM).In rete è possibile trovare diversi driver gratuiti per dischi RAM.Non troverai alcuna unità fisica, inclusi gli SSD, che sia più veloce di un disco RAM.

Nel mio caso, un progetto che ha richiesto 5 minuti per essere realizzato su un i7 a 6 core su un'unità SATA da 7200 RPM con Incredibuild è stato ridotto di soli 15 secondi circa utilizzando un disco RAM.Considerando la necessità di ricopiare su un dispositivo di archiviazione permanente e la potenziale perdita di lavoro, 15 secondi non sono un incentivo sufficiente per utilizzare un disco RAM e probabilmente non sono un grande incentivo a spendere diverse centinaia di dollari su un'unità SSD o ad alto numero di giri.

Il piccolo guadagno potrebbe indicare che la build era legata alla CPU o che la memorizzazione nella cache dei file di Windows era piuttosto efficace, ma poiché entrambi i test sono stati eseguiti da uno stato in cui i file non erano memorizzati nella cache, mi oriento fortemente verso le compilazioni legate alla CPU.

A seconda del codice effettivo che stai compilando, il tuo chilometraggio può variare, quindi non esitare a testare.

Quanto è grande la tua directory di build dopo aver eseguito una build completa?Se mantieni la configurazione predefinita, ogni assembly che crei copierà tutte le DLL delle sue dipendenze e le dipendenze delle sue dipendenze, ecc.nella sua directory bin.Nel mio lavoro precedente, quando lavoravo con una soluzione di circa 40 progetti, i miei colleghi scoprirono che la parte di gran lunga più costosa del processo di creazione era copiare questi assembly più e più volte e che una build poteva generare gigabyte di copie delle stesse DLL più e più volte. ancora una volta.

Ecco alcuni consigli utili da Patrick Smacchia, autore di NDepend, su ciò che secondo lui dovrebbero e non dovrebbero essere assemblee separate:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

Esistono fondamentalmente due modi per aggirare questo problema ed entrambi presentano degli svantaggi.Il primo è ridurre il numero delle assemblee, il che ovviamente comporta molto lavoro.Un altro è ristrutturare le directory di build in modo che tutte le cartelle bin siano consolidate e i progetti non copino le DLL delle loro dipendenze: non è necessario perché sono già tutte nella stessa directory.Ciò riduce drasticamente il numero di file creati e copiati durante una compilazione, ma può essere difficile da configurare e può lasciare con qualche difficoltà nell'estrarre solo le DLL richieste da uno specifico eseguibile per il confezionamento.

Forse prendi alcune funzioni comuni e crea alcune librerie, in questo modo gli stessi sorgenti non verranno compilati più e più volte per più progetti.

Se sei preoccupato che diverse versioni di DLL si confondano, utilizza le librerie statiche.

Disattiva l'integrazione VSS.Potresti non avere scelta nell'usarlo, ma le DLL vengono rinominate "accidentalmente" continuamente...

E controlla sicuramente le impostazioni dell'intestazione precompilata.La guida di Bruce Dawson è un po' vecchia, ma comunque molto bene, dai un'occhiata: http://www.cygnus-software.com/papers/precompiledheaders.html

Ho un progetto che ha 120 o più ex, librerie e DLL e richiede molto tempo per essere costruito.Utilizzo un albero di file batch che chiamano make file da un file batch principale.In passato ho avuto problemi con cose strane derivanti dalle intestazioni incrementali (o erano capricciose), quindi ora le evito.Eseguo una costruzione completa raramente e di solito la lascio alla fine della giornata mentre vado a fare una passeggiata per un'ora (quindi posso solo immaginare che ci voglia circa mezz'ora).Quindi capisco perché ciò è impraticabile per lavorare e testare.

Per lavorare e testare ho un altro set di file batch per ogni app (o modulo o libreria) che ha anche tutte le impostazioni di debug, ma questi chiamano ancora gli stessi file make.Potrei attivare o disattivare DEBUG di tanto in tanto e anche decidere su build o make o se voglio creare anche librerie da cui il modulo può dipendere, e così via.

Il file batch copia anche il risultato completato nelle (o più) cartelle del test.A seconda delle impostazioni, il completamento richiede da alcuni secondi a un minuto (anziché mezz'ora).

Ho usato un IDE diverso (Zeus) perché mi piace avere il controllo su cose come i file .rc e in realtà preferisco compilare dalla riga di comando, anche se sto usando i compilatori MS.

Felice di pubblicare un esempio di questo file batch se qualcuno è interessato.

Disabilita l'indicizzazione del file system nelle directory di origine (in particolare le directory obj se desideri che la tua fonte sia ricercabile)

Se si tratta di un'app Web, l'impostazione di batch build su true può essere utile a seconda dello scenario.

<compilation defaultLanguage="c#" debug="true" batch="true" >

Puoi trovare una panoramica qui: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Potresti anche voler verificare la presenza di riferimenti al progetto circolare.Per me una volta era un problema.

Questo è:

Il progetto A fa riferimento al progetto B

Il progetto B fa riferimento al progetto C

Il progetto C fa riferimento al progetto A

Un'alternativa più economica a Xoreax IB è l'uso di ciò che io chiamo build uber-file.Fondamentalmente è un file .cpp che ha

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Quindi compili le unità uber invece dei singoli moduli.Abbiamo riscontrato tempi di compilazione da 10-15 minuti fino a 1-2 minuti.Potrebbe essere necessario sperimentare quanti #include per file Uber hanno senso.Dipende dai progetti.eccetera.Forse includi 10 file, forse 20.

Paghi un costo quindi fai attenzione:

Non puoi fare clic con il pulsante destro del mouse su un file e dire "compila..." poiché devi escludere i singoli file cpp dalla build e includere solo i file uber cpp
Devi stare attento ai conflitti delle variabili globali statiche.
Quando aggiungi nuovi moduli, devi mantenere aggiornati i file uber

È un po' una seccatura, ma per un progetto che è in gran parte statico in termini di nuovi moduli, la fatica iniziale potrebbe valerne la pena.Ho visto questo metodo battere IB in alcuni casi.

Se si tratta di un progetto C++, dovresti utilizzare intestazioni precompilate.Ciò fa un'enorme differenza nei tempi di compilazione.Non sono sicuro di cosa stia realmente facendo cl.exe (senza utilizzare intestazioni precompilate), sembra che stia cercando molti di intestazioni STL in tutti i posti sbagliati prima di andare finalmente nella posizione corretta.Ciò aggiunge interi secondi a ogni singolo file .cpp compilato.Non sono sicuro che si tratti di un bug di cl.exe o di una sorta di problema STL in VS2008.

Osservando la macchina su cui stai costruendo, è configurata in modo ottimale?

Abbiamo appena ridotto i tempi di costruzione per il nostro più grande prodotto C++ su scala aziendale 19 ore A 16 minuti assicurandosi che sia installato il driver del filtro SATA corretto.

Impercettibile.

Esiste un'opzione /MP non documentata in Visual Studio 2005, vedere http://lahsiv.net/blog/?p=40, che consentirebbe la compilazione parallela su base file anziché su base progetto.Ciò potrebbe accelerare la compilazione dell'ultimo progetto o, se si compila un progetto.

Quando si sceglie una CPU:La dimensione della cache L1 sembra avere un enorme impatto sul tempo di compilazione.Inoltre, di solito è meglio avere 2 core veloci che 4 lenti.Visual Studio non utilizza i core aggiuntivi in modo molto efficace.(Lo baso sulla mia esperienza con il compilatore C++, ma probabilmente è vero anche per quello C#.)

Ora sono anche convinto che ci sia un problema con VS2008.Lo sto eseguendo su un laptop Intel dual core con 3G Ram, con l'antivirus disattivato.La compilazione della soluzione è spesso piuttosto fluida, ma se ho eseguito il debug di una successiva ricompilazione spesso rallenterà fino alla scansione.È chiaro dalla luce continua del disco principale che esiste un collo di bottiglia I/O del disco (puoi anche sentirlo).Se annullo la compilazione e l'arresto di VS, l'attività del disco si interrompe.Riavvia VS, ricarica la soluzione e quindi ricostruisci, ed è molto più veloce.Fino alla prossima volta

Il mio pensiero è che si tratti di un problema di paging della memoria: VS esaurisce la memoria e il sistema operativo avvia lo scambio di pagine per cercare di fare spazio, ma VS richiede più di quanto lo scambio di pagine può fornire, quindi rallenta fino alla scansione.Non riesco a pensare a nessun'altra spiegazione.

VS sicuramente non è uno strumento RAD, vero?

Per caso la tua azienda utilizza Entrust per la propria soluzione PKI/crittografia?Si è scoperto che stavamo riscontrando prestazioni di costruzione pessime per un sito Web abbastanza grande creato in C#, impiegando più di 7 minuti su un Rebuild-All.

La mia macchina è un i7-3770 con 16 GB di RAM e un SSD da 512 GB, quindi le prestazioni non avrebbero dovuto essere così male.Ho notato che i miei tempi di costruzione erano incredibilmente più veloci su una macchina secondaria più vecchia che costruiva la stessa base di codice.Quindi ho avviato ProcMon su entrambe le macchine, ho profilato le build e ho confrontato i risultati.

Ed ecco, la macchina dalle prestazioni lente aveva una differenza: un riferimento a Entrust.dll nello stacktrace.Utilizzando queste informazioni appena acquisite, ho continuato a cercare StackOverflow e ho trovato questo: MSBUILD (VS2010) molto lento su alcune macchine.Secondo la risposta accettata, il problema risiede nel fatto che il gestore Entrust stava elaborando i controlli dei certificati .NET anziché il gestore Microsoft nativo.Si suggerisce inoltre che Entrust v10 risolva questo problema prevalente in Entrust 9.

Al momento l'ho disinstallato e i miei tempi di costruzione sono crollati 24 secondi.YYMV con il numero di progetti che stai attualmente creando e potrebbe non risolvere direttamente il problema di ridimensionamento per il quale stavi chiedendo informazioni.Pubblicherò una modifica a questa risposta se posso fornire una soluzione senza ricorrere ad una disinstallazione del software.

È sicuro che c'è un problema con VS2008.Perché l'unica cosa che ho fatto è installare VS2008 per aggiornare il mio progetto che è stato creato con VS2005.Ho solo 2 progetti nella mia soluzione.Non è grande.Compilazione con VS2005:Compilation di 30 secondi con VS2008:5 minuti

Suggerimenti utili che ci hanno aiutato finora (non dico che non ci siano altri suggerimenti utili di seguito, se riscontri problemi, ti consiglio di leggere, proprio quello che ci ha aiutato)

Nuovo laptop da 3 GHz: la potenza della perdita di utilizzo fa miracoli quando si lamenta il management
Disattiva l'antivirus durante la compilazione
"Disconnessione" da VSS (in realtà la rete) durante la compilazione: potrei convincerci a rimuovere del tutto l'integrazione VS-VSS e continuare a utilizzare l'interfaccia utente VSS

Ancora non riesco a sniffare una compilazione, ma ogni cosa aiuta.

Stiamo anche testando la pratica di costruire nuove aree dell'applicazione in nuove soluzioni, importando le DLL più recenti come richiesto, integrandole nella soluzione più ampia quando ne siamo soddisfatti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow