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

Molto di questo è dovuto alle dimensioni della nostra soluzione che è cresciuta fino a oltre 70 progetti, così come al VSS che è un collo di bottiglia in sé quando hai molti file. (lo scambio di VSS non è purtroppo un'opzione, quindi non voglio che questo scenda in un VSS bash)

Stiamo esaminando la fusione di progetti. Stiamo inoltre cercando soluzioni multiple per ottenere una maggiore separazione dei problemi e tempi di compilazione più rapidi per ciascun elemento dell'applicazione. Questo che vedo diventerà un inferno DLL mentre cerchiamo di mantenere le cose in sincronia.

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 perdendo mezza giornata guardando la barra di stato consegnare i messaggi di compilazione.

AGGIORNAMENTO Ho dimenticato di menzionare questa è una soluzione C #. Grazie per tutti i suggerimenti C ++, ma sono passati alcuni anni da quando ho dovuto preoccuparmi delle intestazioni.

MODIFICARE:

Bei suggerimenti che hanno aiutato finora (senza dire che non ci sono altri buoni suggerimenti qui sotto, proprio quello che ha aiutato)

• Nuovo laptop 3GHz: la potenza dell'utilizzo perduto fa miracoli quando si lamenta della gestione
• Disabilita Anti Virus durante la compilazione
• Disconnessione da VSS (in realtà la rete) durante la compilazione - Potrei farci rimuovere del tutto l'integrazione VS-VSS e continuare a utilizzare l'interfaccia utente VSS

Ancora non rippare sbuffando attraverso una compilazione, ma tutto aiuta.

Orion ha menzionato in un commento che anche i generici possono recitare. Dai miei test sembra esserci un impatto minimo sulle prestazioni, ma non abbastanza alto da essere certo: 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, come apparirebbero nel sistema live, quindi potrebbero accumularsi. Non eviterei di usare i generici dove dovrebbero essere usati, solo per le prestazioni in fase di compilazione

SOLUZIONE

Stiamo testando la pratica di costruire nuove aree dell'applicazione in nuove soluzioni, importando nelle ultime DLL 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 gettandole via dopo aver reintegrato il codice. Dobbiamo valutare il tempo necessario per reintegrare questo codice rispetto al tempo che guadagniamo non avendo Rip Van Winkle come esperienze con una ricompilazione rapida durante lo sviluppo.

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

In ordine decrescente di velocità:

• Installare l'aggiornamento rapido Microsoft 935225 .
• Installare l'aggiornamento rapido Microsoft 947315 .
• Utilizzare un vero processore multicore (ovvero un Intel Core Duo 2; non un Pentium 4 HT).
• Usa 3 build parallele. In Visual Studio 2005 troverai l'opzione in Strumenti> Opzioni ...> Progetti e soluzioni> Crea ed esegui> numero massimo di build di progetti parallele .
• Disabilita il tuo software antivirus per i file .ilk, .pdb, .cc, .h e controlla solo i virus durante la modifica . 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 accelera davvero la build, ma almeno il tuo computer rimarrà reattivo quando esegui la sincronizzazione di gclient o una build.
• Deframmenta il tuo disco rigido regolarmente.
• Disabilita la memoria virtuale.

Abbiamo quasi 100 progetti in una soluzione e un tempo di sviluppo degli sviluppatori di soli secondi :)

Per lo sviluppo locale costruisce abbiamo creato un Visual Studio Addin che le modifiche Project referencesalle DLL referencese scarica il progetti indesiderati (e la possibilità di passare di nuovo, naturalmente).

• Costruisci la nostra intera soluzione una volta
• Scarica i progetti su cui non stiamo attualmente lavorando e modifica tutti i riferimenti ai riferimenti DLL.
• Prima del check-in cambia tutti i riferimenti dalla DLL ai riferimenti di progetto.

Le nostre build ora impiegano solo pochi secondi quando stiamo lavorando a pochi progetti alla volta. Possiamo anche ancora eseguire il debug dei progetti aggiuntivi in ​​quanto si collega alle DLL di debug. Lo strumento richiede in genere 10-30 secondi per apportare un gran numero di modifiche, ma non è necessario farlo spesso.

Aggiornamento maggio 2015

L'accordo che ho fatto (nei commenti sotto) era che avrei rilasciato il plugin su Open Source se avesse avuto 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 avuto un problema simile su una soluzione con 21 progetti e 1/2 milione di LOC. La differenza più grande era ottenere dischi rigidi più veloci. Dal monitor delle prestazioni, la "Media. Disk Queue 'salterebbe significativamente sul laptop indicando che il disco rigido era il collo della bottiglia.

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

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

Tempo di ricostruzione = 112 secondi.

2) Desktop (problema standard), Core 2 Duo 2.3Ghz, singola cache da 8 MB da 7200 giri / min.

Tempo di ricostruzione = 72 secondi.

3) Desktop Core 2 Duo 3Ghz, singolo 10000 RPM WD Raptor

Tempo di ricostruzione = 39 secondi.

L'unità da 10.000 RPM non può essere sottovalutata. Costruisce in modo significativamente più veloce oltre a qualsiasi altra cosa come la visualizzazione della documentazione, l'utilizzo di Esplora file è stato notevolmente più rapido. È stato un grande aumento della produttività accelerando il ciclo di esecuzione del codice.

Dato ciò che le aziende spendono per gli stipendi degli sviluppatori, è pazzesco quanto possono sprecare acquistare equipaggiandoli con gli stessi PC utilizzati dall'addetto alla reception.

Per le build C # .NET, puoi usare .NET Demon . È un prodotto che prende 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 basano effettivamente sulle modifiche apportate. Ciò significa che se si modifica solo il codice interno, è necessario creare solo un progetto.

Disattiva il tuo antivirus. Aggiunge età al tempo di compilazione.

Usa compilation distribuita. Xoreax IncrediBuild può ridurre i tempi di compilazione in 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

Purtroppo Visual Studio non è abbastanza intelligente da distinguere le modifiche dell'interfaccia di un assembly dalle modifiche non rilevanti del corpo del codice. Questo fatto, quando combinato con una grande soluzione intrecciata, a volte può creare una tempesta perfetta di "build complete" indesiderate quasi ogni volta che si cambia una singola riga di codice.

Una strategia per ovviare a questo è disabilitare le build automatiche dell'albero di riferimento. Per fare questo, usa 'Configuration Manager' (Build / Configuration Manager ... quindi nel menu a discesa Configurazione soluzione attiva, scegli 'Nuovo') per creare una nuova configurazione di build chiamata 'ManualCompile' che copia dalla configurazione di Debug, ma non selezionare la casella di controllo "Crea nuove configurazioni di progetto". In questa nuova configurazione di compilazione, deseleziona tutti i progetti in modo che nessuno di essi verrà compilato 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 "Rilascio"). In effetti questa nuova configurazione di compilazione ManualCompile renderà inutili le opzioni del menu Build per: 'Build Solution' o 'Rebuild Solution'. Pertanto, quando ci si trova in modalità ManualCompile, è necessario creare manualmente ogni progetto che si sta modificando, il che può essere fatto facendo clic con il tasto destro su ciascun progetto interessato in Esplora soluzioni, quindi selezionando 'Costruisci' o 'Ricostruisci'. Dovresti vedere che i tuoi tempi complessivi di compilazione saranno ora solo pochi secondi.

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

Un potenziale rischio derivante dall'utilizzo di questa strategia di compilazione manuale è che lo sviluppatore potrebbe dimenticare di compilare i progetti richiesti e quando avviano il debugger ottengono risultati imprevisti (impossibile allegare il debugger, file non trovati, ecc.). Per evitarlo, è probabilmente consigliabile utilizzare la configurazione di build "Debug" per compilare uno sforzo di codifica più ampio e utilizzare la configurazione di compilazione ManualCompile solo durante i test dell'unità o per apportare modifiche rapide che hanno un ambito limitato.

Se questo è C o C ++ e non stai usando intestazioni precompilate, dovresti esserlo.

Avevamo oltre 80 progetti nella nostra soluzione principale che impiegava dai 4 ai 6 minuti per essere costruita a seconda del tipo di macchina che stava lavorando uno sviluppatore. Abbiamo ritenuto che fosse troppo lungo: per ogni singolo test si consuma davvero i tuoi ETP.

Quindi, come ottenere tempi di costruzione più rapidi? Come sembra già sapere, è il numero di progetti che ha davvero danneggiato il tempo di costruzione. Ovviamente non volevamo sbarazzarci di tutti i nostri progetti e semplicemente buttare tutti i file sorgente in uno. Ma avevamo alcuni progetti che potevamo comunque combinare: dato che ogni "progetto repository" nella soluzione aveva il suo progetto unittest, abbiamo semplicemente combinato tutti i progetti unittest in un 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.

Tuttavia stiamo pensando a un'altra soluzione.

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

Tuttavia, lavorare con due diverse soluzioni prenderà in considerazione attentamente. Gli sviluppatori potrebbero essere inclini a lavorare effettivamente nella seconda soluzione e trascurare completamente la prima. Poiché la prima soluzione con oltre 70 progetti sarà la soluzione che si occuperà 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 l'integrazione continua deve essere il primo progetto / soluzione. Devi mantenere la tua gerarchia di oggetti, giusto.

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

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

Inoltre, impostali in modo che non vengano copiati localmente, tranne se assolutamente necessario (il progetto EXE principale).

Originariamente ho pubblicato questa risposta qui: /programming/8440/visual-studio-optimizations#8473 Puoi trovare molti altri suggerimenti utili su quella pagina.

Se si utilizza Visual Studio 2008, è possibile compilare utilizzando il flag / MP per creare un singolo progetto in parallelo. Ho letto che questa è anche una caratteristica non documentata in Visual Studio 2005, ma non ho mai provato me stesso.

È possibile creare più progetti in parallelo utilizzando il flag / M, ma questo di solito è già impostato sul numero di core disponibili sulla macchina, anche se questo vale solo per VC ++.

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

Alcune risorse aggiuntive:

• /programming/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

Alcuni strumenti di analisi:

strumenti-> opzioni-> impostazioni del progetto VC ++ -> Tempi di costruzione = Sì ti dirà il tempo di costruzione per ogni vcproj.

Aggiungi /Btswitch alla riga di comando del compilatore per vedere quanto ogni file CPP ha impiegato

Utilizzare /showIncludesper catturare le inclusioni nidificate (file di intestazione che includono altri file di intestazione) e vedere quali file potrebbero salvare molti IO usando dichiarazioni forward.

Ciò ti aiuterà a ottimizzare le prestazioni del compilatore eliminando dipendenze e maiali delle prestazioni.

Prima di spendere soldi per investire in dischi rigidi più veloci, prova a costruire il tuo progetto interamente su un disco RAM (supponendo che tu abbia la RAM da risparmiare). È possibile trovare vari driver di disco RAM gratuiti in rete. Non troverai alcuna unità fisica, inclusi gli SSD, più veloce di un disco RAM.

Nel mio caso, un progetto che ha impiegato 5 minuti per essere costruito su un i7 a 6 core su un'unità SATA a 7200 RPM con Incredibuild è stato ridotto di soli 15 secondi circa utilizzando un disco RAM. Considerando la necessità di ricopiare la memoria permanente e il potenziale di perdita di lavoro, 15 secondi non sono incentivi sufficienti per utilizzare un disco RAM e probabilmente non sono molto incentivi per spendere diverse centinaia di dollari su un disco ad alto RPM o SSD.

Il piccolo guadagno può 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 sono fortemente appoggiato alle compilazioni associate alla CPU.

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

Quanto è grande la tua directory di build dopo aver fatto una build completa? Se si mantiene l'impostazione predefinita, ogni assembly creato copierà tutte le DLL delle sue dipendenze, delle sue dipendenze, ecc. Nella relativa directory bin. Nel mio lavoro precedente quando lavoravo con una soluzione di circa 40 progetti, i miei colleghi hanno scoperto che la parte di gran lunga più costosa del processo di compilazione era la copia ripetuta di questi assiemi e che una generazione poteva generare gigabyte di copie delle stesse DLL ancora e ancora di nuovo.

Ecco alcuni consigli utili di Patrick Smacchia, autore di NDepend, su ciò che crede dovrebbe e non dovrebbe 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 hanno degli svantaggi. Uno è quello di ridurre il numero di assiemi, che ovviamente richiede molto lavoro. Un altro è quello di ristrutturare le directory di compilazione in modo che tutte le cartelle bin siano consolidate e che i progetti non copino le DLL delle loro dipendenze - non è necessario perché sono già tutti nella stessa directory. Ciò riduce drasticamente il numero di file creati e copiati durante una compilazione, ma può essere difficile da configurare e può avere qualche difficoltà a estrarre solo le DLL richieste da un eseguibile specifico per il packaging.

Forse prendi alcune funzioni comuni e crea alcune librerie, in questo modo le stesse fonti non vengono compilate più e più volte per più progetti.

Se sei preoccupato per le diverse versioni di DLL che si confondono, usa le librerie statiche.

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

E sicuramente controlla le tue impostazioni di intestazione precompilate. La guida di Bruce Dawson è un po 'vecchia, ma comunque molto buona. 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 un tempo considerevole per essere costruito. Uso un albero di file batch che chiama make file da un file batch master. Ho avuto problemi con cose strane da intestazioni incrementali (o era temperamentale) in passato, quindi le evito ora. Faccio una build completa di rado e di solito la lascio alla fine della giornata mentre vado a fare una passeggiata per un'ora (quindi posso solo immaginare che ci vuole circa mezz'ora). Quindi capisco perché non è realizzabile 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 in atto - ma queste chiamano comunque gli stessi file make. Di tanto in tanto potrei attivare o disattivare DEBUG e anche decidere su build o marche o se voglio anche creare librerie da cui il modulo potrebbe dipendere, e così via.

Il file batch copia anche il risultato completato nelle (o più) cartelle di test. A seconda delle impostazioni, questo si completa in alcuni secondi a un minuto (al contrario di mezz'ora).

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

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

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

Se si tratta di un'app Web, l'impostazione della compilazione batch su true può aiutare 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

Puoi anche verificare i riferimenti circolari al progetto. È stato un problema per me una volta.

Questo è:

Progetto A riferimenti Progetto B

Riferimenti al Progetto B Progetto C

Riferimenti al Progetto C Progetto A

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

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

Quindi compili le unità uber anziché i singoli moduli. Abbiamo visto tempi di compilazione da 10-15 minuti a 1-2 minuti. Potrebbe essere necessario sperimentare quanti # inclusioni per ogni tuo file abbiano senso. Dipende dai progetti. ecc. Forse includi 10 file, forse 20.

Paghi un costo quindi fai attenzione:

1. Non è possibile fare clic con il pulsante destro del mouse su un file e pronunciare "compila ..." poiché è necessario escludere i singoli file cpp dalla build e includere solo i file upp cpp
2. Devi stare attento ai conflitti di variabili globali statiche.
3. Quando aggiungi nuovi moduli, devi mantenere aggiornati i file uber

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

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

Guardando la macchina su cui stai costruendo, è configurato in modo ottimale?

Abbiamo appena ridotto i tempi di costruzione del nostro più grande prodotto su scala aziendale C ++ da 19 ore a 16 minuti assicurandoci che fosse installato il driver del filtro SATA giusto.

Delicato.

In Visual Studio 2005 è disponibile l'opzione MP / non documentata, vedere http://lahsiv.net/blog/?p=40 , che consentirebbe la compilazione parallela su base file anziché su base progetto. Ciò può 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 impatto enorme sui tempi di compilazione. Inoltre, di solito è meglio avere 2 core veloci rispetto a 4 core lenti. Visual Studio non utilizza i core aggiuntivi in ​​modo molto efficace. (Baso questo sulla mia esperienza con il compilatore C ++, ma probabilmente è anche vero per il C # uno.)

Sono anche ora convinto che ci sia un problema con VS2008. Lo sto eseguendo su un laptop Intel dual core con 3G Ram, con l'antivirus disattivato. Compilare la soluzione è spesso piuttosto semplice, ma se ho eseguito il debug di una ricompilazione successiva spesso rallenterà fino a una scansione. Dalla luce continua del disco principale è chiaro che esiste un collo di bottiglia di I / O del disco (è possibile anche ascoltarlo). Se annullo la generazione e l'arresto VS l'attività del disco si interrompe. Riavvia VS, ricarica la soluzione e poi ricostruisci, ed è molto più veloce. Unitl la prossima volta

Il mio pensiero è che si tratti di un problema di paging della memoria: VS esaurisce la memoria e O / S avvia lo scambio di pagine per cercare di liberare spazio, ma VS richiede più di quanto lo scambio di pagine sia in grado di fornire, quindi rallenta a una scansione. Non riesco a pensare ad altre spiegazioni.

VS sicuramente non è uno strumento RAD, vero?

La tua azienda utilizza per caso Entrust per la loro soluzione PKI / Crittografia? Si scopre che stavamo ottenendo prestazioni di costruzione spaventose per un sito Web abbastanza grande costruito in C #, impiegando più di 7 minuti su un Rebuild-All.

La mia macchina è un i7-3770 con ram da 16 GB e un SSD da 512 GB, quindi le prestazioni non avrebbero dovuto essere così negative. Ho notato che i miei tempi di costruzione erano follemente 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 confrontato i risultati.

Ecco, la macchina dalle prestazioni lente aveva una differenza: un riferimento a Entrust.dll nello stacktrace. Usando 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 del certificato .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 a 24 secondi . YYMV con il numero di progetti attualmente in fase di realizzazione e potrebbe non essere in grado di risolvere direttamente il problema di ridimensionamento di cui si stava indagando. Invierò una modifica a questa risposta se posso fornire una correzione senza ricorrere a 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: 30 secondi Compilazione con VS2008: 5 minuti

Simpatici suggerimenti che ci hanno aiutato finora (senza dire che non ci sono altri simpatici suggerimenti di seguito, se hai problemi, ti consiglio di leggere allora, proprio quello che ci ha aiutato)

• Nuovo laptop 3GHz: la potenza dell'utilizzo perduto fa miracoli quando si lamenta della gestione
• Disabilita Anti Virus durante la compilazione
• Disconnessione da VSS (in realtà la rete) durante la compilazione - Potrei farci rimuovere del tutto l'integrazione VS-VSS e continuare a utilizzare l'interfaccia utente VSS

Ancora non rippare sbuffando attraverso una compilazione, ma tutto aiuta.

Stiamo anche testando la pratica di costruire nuove aree dell'applicazione in nuove soluzioni, importando nelle ultime DLL 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 gettandole via dopo aver reintegrato il codice. Dobbiamo valutare il tempo necessario per reintegrare questo codice rispetto al tempo che guadagniamo non avendo Rip Van Winkle come esperienze con una ricompilazione rapida durante lo sviluppo.

Orion ha menzionato in un commento che anche i generici possono recitare. Dai miei test sembra esserci un impatto minimo sulle prestazioni, ma non abbastanza alto da essere certo: 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, come apparirebbero nel sistema live, quindi potrebbero accumularsi. Non eviterei di usare i generici dove dovrebbero essere usati, solo per le prestazioni in fase di compilazione