Sto utilizzando VS2008, in una normale soluzione di medie dimensioni.Debugging a volte molto lento
A volte, eseguire il debug di stepping diventa molto lento. Un lucchetto viene sottoposto a rendering su ogni scheda del file per ogni "passo" (F10/F11) e può richiedere fino a due secondi per ogni passaggio. Ciò rende il debug molto fastidioso e lento. qualcuno ha notato questo problema?
Sì, Visual Studio è estremamente lento a debug a volte ci sono una serie di passaggi aggiuntivi (oltre a disattivare l'impostazione Abilita valutazione proprietà ") che è possibile adottare per accelerare il processo. Essenzialmente, richiede enormi quantità di RAM, quindi eseguire alcune cose per liberare ciò aiuterà.
Vai nelle preferenze di Visual Studio. Cerca tutte le opzioni relative all'animazione dei menu e così via. Questi tendono ad essere intensi a volte, mentre non specifici per il debug come di solito non si aprono i menu, sembra aiutare.
Sul computer stesso, se si fa clic con il pulsante destro del mouse sul computer. Vai alla scheda Avanzate e sotto le prestazioni. Se regoli il tuo computer per ottenere le migliori prestazioni, accelererai le cose. Si sbarazza di tutti i bei stili sul tuo computer, ma ti libererà parte della memoria che desideri.
Chiudere tutti i programmi non necessari. Più memoria puoi dare a Visual Studio, migliore sarà il comportamento.
@kaze Ho analizzato molti rallentamenti di Visual Studio e non li ho mai visti come un fattore significativo. 1) I menu non devono animare in modo significativo durante il debug, specialmente se si utilizzano le scorciatoie da tastiera per il passo singolo. 2) Qualsiasi macchina ragionevolmente potente (memoria sufficiente, CPU, GPU ragionevole) può gestire le impostazioni predefinite delle prestazioni. 3) L'ultimo consiglio si applica solo se il tuo computer non ha memoria sufficiente. Mostra thread in origine e punti di interruzione eccessivi possono far sì che Visual Studio esegua ordini di grandezza più lentamente. Le risposte che suggeriscono sono molto più utili. –
Provare a disattivare la "valutazione Abilita proprietà ...” impostazione nelle opzioni di debugger, si dovrebbe fare il debug molto più veloce (leggi: Fix: Make Debugging Faster with Visual Studio):
Here's a link to some guidance on Mike Stahl's MSDN blog, rispetto alla risoluzione dei rallentamenti debugger
mi sono imbattuto in questo, perché i punti di interruzione condizionali in hotspot del mio app hanno ucciso la mia prestazione di debug. BKM personale: risolvi potenziali problemi di prestazioni prima di partire per la notte, perché potresti non ricordarli al mattino.
Ho notato in VS 2008 che se si seleziona il pulsante "Mostra thread in origine" nella barra degli strumenti di debug, lo stepping può essere almeno 10 volte più lento.
Ho anche notato che se l'applicazione impiega molto tempo per l'avvio in modalità di debug, è possibile risolverlo semplicemente con "Elimina tutti i punti di interruzione" nel menu Debug. Questo mi ha risolto un problema fastidioso anche se avevo solo una serie di punti di interruzione impostati in quel momento.
Silas
Disabilitare Mostra Discussioni del codice sorgente in Visual Studio. e Chiudi chiamata traccia Traccia Finestra.
+1 ha funzionato per me :). – MichaelMocko
In aggiunta a tutte le questioni di cui sopra.
Una scheda "Smontaggio" (aperta in uno sfondo) rallenta il debug di 1-2 secondi per passaggio. (Non sono sicuro se succede sempre così).
Questo è stato il mio caso, disattivando la valutazione delle proprietà è stato utile, ma chiudendo le finestre di disassemblaggio il debug è stato reso molto più veloce (da circa 3 secondi a un passo indietro fino a quasi un istante) ... grazie! – Martin
Ho avuto lo stesso problema, soprattutto durante il debug di app con molti thread.
È stato causato dalla funzionalità "Mostra thread in origine".
consultare il seguente link per ulteriori informazioni:
Code Project: Show threads in source
Visual Studio Single Step Performance Fixes
Dopo aver disabilitato questa funzionalità, problema è stato risolto.
Ci sono molte cose che possono far rallentare Visual Studio. I breakpoint eccessivi e Mostra thread in origine sono probabilmente i due più comuni, ma non ti interessa ciò che è più comune, ti interessa cosa rende Visual Studio lento per * tu *.
Pertanto, se l'eliminazione di punti di interruzione e disattivazione di Mostra thread in Source non funziona, è necessario definire il profilo di Visual Studio. Questo ti permette di trovare problemi di prestazioni che sono unici per la tua situazione. Una spiegazione di come fare questo (che ha risolto due problemi di prestazioni Visual Studio separati) può essere trovato qui:
http://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/
Più indagini dei problemi di prestazioni in codice di altre persone sono dettagliate qui:
http://randomascii.wordpress.com/category/investigative-reporting/
Un'altra causa della lentezza di un singolo passo è l'uso di Intellitrace (disponibile solo in Ultimate). Per disattivarlo, Strumenti | Opzioni | IntelliTrace. Deseleziona Abilita IntelliTrace.
Il suggerimento "Mostra thread in origine" non ha aiutato.
Ma l'ho risolto abilitando Strumenti: Opzioni: Debug: Generale -> "Richiede che i file di origine corrispondano esattamente alla versione originale".
Inizialmente la miniera non era selezionata, ma dopo averla modificata, il codice in VS2008 è tornato alla velocità normale.
cancella tutte le voci nella finestra di controllo.
Grazie per la risposta, ma potresti fornire ulteriori informazioni su questa soluzione? Perché dovrebbe risolvere il problema, come risolverebbe il problema, ecc. – Hiphop03199
Ciò che mi ha aiutato è stata la disattivazione degli strumenti di diagnostica.
Strumenti/Opzioni/Debug/Generale/Attiva Strumenti di diagnostica
Visual Studio 2015 (versione 14)
ho sperimentato questo problema dopo aver abilitato ".NET Framework fonte stepping". Il passo è diventato molto più veloce dopo averlo disattivato. In particolare, riattivare "Abilita solo il mio codice" (Opzioni> Debug> Generale) rimosso circa la metà del ritardo che stavo vivendo.
L'altra metà è stata causata dal caricamento di più simboli del necessario (Opzioni> Debug> Simboli). A un certo punto mi servivano le posizioni dei simboli definite, ma non l'ho più fatto, quindi sono stato in grado di deselezionarle tutte e fare clic su "Empty Symbol Cache". Se hai elencato _NT_SYMBOL_PATH significa che hai definito questa impostazione dell'ambiente e Visual Studio non ti permetterà di deselezionarlo. Dovrai rimuovere l'impostazione. Ulteriori informazioni sulle impostazioni dei simboli (https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/05/understanding-symbol-files-and-visual-studios-symbol-settings/)
Ho avuto lo stesso problema, ho eliminato tutti i miei orologi variabili e mi ha aiutato molto!Perché ogni passo durante il debug, ricarica tutti gli orologi e ci vuole tempo ...
Soluzione: Dal menu Debug, scegli Windows, quindi Guarda e fai clic su Watch1, Watch2, Watch3 o Watch4. Apparirà il menu e fare clic con il tasto destro su di essi per cancellarli tutti.
Se si dispone di uno scanner antivirus (con scansioni in tempo reale abilitate), verificare se C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe * è escluso dalla scansione.
Nel mio caso, il debug è diventato molto lento dopo l'implementazione a livello aziendale del nuovo programma antivirus. Dopo un po ', abbiamo scoperto che la scansione in tempo reale di msvsmon.exe era il colpevole.
* modifica percorso come da cartella di installazione
Domanda vecchia come sporcizia, ma ancora rilevante visto che mi è appena successo. Nel mio caso, la risposta era semplicemente quella di assicurarsi che la finestra "Call Stack" non fosse attiva. Di solito è impilato insieme a "Auto", "Locali" e "Guarda", quindi basta fare clic su uno di quelli per mettere "Call Stack" in background. – JPNotADragon
wrt @ JPNotADragon's answer: disattivando la finestra dello stack di chiamate (cioè passando a un'altra finestra) risolveva magicamente i miei problemi perf mentre eseguivo il debug (stepping oltre che ispezionare le variabili). Cosa c'è di più, i problemi di perf non sono tornati dopo ** re ** attivando la finestra dello stack delle chiamate. – bvgheluwe