Tempo di tracciamento trascorso nel debugger

Question

[[EDIT 2x] Penso di aver formulato la mia domanda originale in modo errato, quindi l'ho spostato in basso e ho riscritto esattamente quello che sto cercando di ottenere, per i futuri lettori. ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~
[Nuovo, Brillante, discosta domanda con una migliore formulazione]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~

Ho un ciclo che è in esecuzione per un quadro di simulazione/gioco. Questo ciclo ha diversi punti in cui è necessario accertare quanto tempo - in realtà - è passato, in modo che la logica all'interno di questi posti speciali - in particolare, Rendering e Aggiornamento - possa funzionare correttamente. Ha la possibilità di essere un passo a tempo fisso (unfixed[update/render] è falso) o no.

Il problema sorge quando il debug basato su punti di interruzione viene eseguito in qualsiasi punto dell'applicazione, poiché utilizza un cronometro per calcolare quanto tempo reale è passato (a fini di fisica e animazione muovendosi a una velocità realistica, e non in base a quanti fotogrammi il computer può sfornare).

Sembra (grosso modo) in questo modo, utilizzando multiple cronometri per ogni 'parte' del ciclo di applicazione che ha bisogno di sapere quanto tempo è passato da quel 'parte' avvenuto lo scorso:

while (RunningTheSimulation) { 
    /* ... Events and other fun awesome stuff */ 

    TimeSpan updatedifference = new TimeSpan(updatestopwatch.ElapsedTicks); 

    if (unfixedupdate || updatedifference > updateinterval) { 

     Time = new GameTime(updatedifference, 
            new TimeSpan(gamestopwatch.ElapsedTicks)); 
     Update(Time); 
     ++updatecount; 
     updatestopwatch.Reset(); 
     updatestopwatch.Start(); 
    } 

    TimeSpan renderdifference = new TimeSpan(renderstopwatch.ElapsedTicks); 

    if (unfixedrender || renderdifference > renderinterval) { 

     Time = new GameTime(renderdifference, 
           new TimeSpan(gamestopwatch.ElapsedTicks)); 
     Render(Time); 
     ++rendercount; 
     renderstopwatch.Reset(); 
     renderstopwatch.Start(); 

    } 
} 

Alcune informazioni sulle variabili:

updatestopwatch è un Stopwatch per il tempo trascorso al di fuori della funzione Update(),

renderstopwatch è un Stopwatch per il tempo trascorso fuori della funzione render(), e

gamestopwatch è un Stopwatch per il tempo totale trascorso della simulazione/gioco stesso.

Il problema si verifica quando eseguo il debug in qualsiasi punto dell'applicazione. Poiché i cronometri misurano in tempo reale, la simulazione verrà completamente eliminata da qualsiasi tipo di debug basato su punti di interruzione perché i cronometri manterranno il tempo di conteggio, indipendentemente dal fatto che esegua il debug dell'applicazione. Non sto utilizzando i cronometri per misurare le prestazioni: li sto utilizzando per tenere traccia del tempo tra le ripetizioni di aggiornamento, rendering e altri eventi come quelli illustrati sopra. Ciò diventa estremamente frustrante quando creo un breakpoint e analizzo e correggo un errore in Update(), ma in tal caso il tempo di Render() è così completamente fuori che qualsiasi visualizzazione dei risultati della simulazione viene lanciata in modo vendicativo in faccia.

Detto questo, quando smetto di eseguire il debug del tutto, ovviamente non è un problema, ma ho un sacco di lavoro di sviluppo da fare e ho intenzione di eseguire il debug per molto tempo, quindi faccio finta che non sia scomodo non funzionerà, sfortunatamente = [

Ho esaminato i contatori delle prestazioni, ma non riesco a spiegarmi come farli funzionare nel contesto di ciò che sto cercando di fare: Render e Update possono contenere qualsiasi quantità di arbitrario codice (sono specifici per qualsiasi simulazione è in esecuzione su questo ciclo while), il che significa che non posso fare costantemente un PerformanceCounter.Increment() per i singoli componenti del ciclo.

Continuerò a curiosare su System.Diagnostics e altri spazi dei nomi .NET, ma finora ho trovato degli spazi vuoti su come "ignorare" il tempo trascorso nel debugger allegato ...

Qualcuno ha idee o idee?

[[EDITS 5x] Corretti errori di ortografia e assicurati che la formattazione di tutto fosse corretta. Mi dispiace per quello ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[originale, domanda meno chiara]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ho un ciclo costante in esecuzione in un'applicazione C#, che eseguire il debug tutto il tempo. Attualmente sto usando un cronometro, ma potrei usare qualsiasi altro meccanismo per tracciare il tempo che passa. Il mio problema inizia quando faccio cose come l'uso di punti di interruzione da qualche parte durante questo ciclo (racchiuso in una tipica while (true) { ... }:

if (unfixedupdate || updatedifference > updateinterval) 
{ 
    Time = new GameTime(updatedifference, 
         new TimeSpan(gamestopwatch.ElapsedTicks)); 
    Update(Time); 
    ++updatecount; 
    updatestopwatch.Reset(); 
    updatestopwatch.Start(); 
} 

Le misure di tempo per sé bene, ma misura il tempo effettivo reale - compreso qualsiasi tempo che ho trascorso il debug. Il che significa che se metto in giro per 17 secondi dopo lo updatestopwatch.Reset(), questo viene aggiunto al mio ciclo e - per almeno 1 ripetizione di quel ciclo - devo occuparmi del tempo extra trascorso in factoring in tempo reale in tutti i miei calcoli

C'è un modo che posso collegare al debugger per sapere quando si blocca l'applicazione, quindi posso contare er-misurare il tempo e sottrarlo di conseguenza? Come taggato, sto usando .NET e C# per questo, ma qualsiasi cosa relativa a Visual Studio potrebbe aiutare a farmi andare nella giusta direzione.

[EDIT] Per fornire ulteriori informazioni, sto utilizzando diversi cronometri (per l'aggiornamento, il rendering e alcuni altri eventi tutti in una coda di messaggi diversa). Se imposto un breakpoint all'interno di Update() o in qualsiasi altra parte dell'applicazione, i cronometri misureranno accuratamente il tempo reale trascorso tra questi. Questo include il tempo speso per il debug di vari componenti della mia applicazione completamente indipendenti che sono denominati a valle di Update() o Render() o Input() ecc. Ovviamente il tempo di simulazione (controllato dal parametro GameTime passato alle funzioni di aggiornamento, rendering, ecc.) Non sarà funziona correttamente se, anche se la CPU impiega solo 13 ms per terminare la funzione di aggiornamento, spendo 13 secondi di debug in più (guardando le variabili e poi Continua con la simulazione); il problema è che vedrò improvvisamente gli altri cronometri che rappresentano 13 in più di secondi di tempo. Se ancora non ha senso, tornerò a suonare.

Answer 1

Utilizzare invece contatori delle prestazioni. Il tempo della CPU del processo dovrebbe fornire un buon indicatore (ma non così preciso come un cronometro in tempo reale) e non dovrebbe interferire con il debug.

Answer 2

Una possibile soluzione sarebbe quella di scrivere i dati locali (o qualsiasi dato che si sta cercando di eseguire il debug) sull'output utilizzando Debug.WriteLine().