Tracking-Zeit im Debugger

Question

[[EDIT 2x] Ich denke, ich habe meine ursprüngliche Frage falsch formuliert, so habe ich es unten geschoben und schrieb genau, was ich versuche zu bekommen, für zukünftige Leser. ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~
[Neu, Schwarz, klare Frage mit besserem Wording]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~

Ich habe eine Schleife, die für eine Simulation/Gaming-Framework läuft. Diese Schleife hat mehrere Stellen, an denen sie feststellen muss, wie viel Zeit - in Wirklichkeit - verstrichen ist, damit die Logik an diesen speziellen Stellen - insbesondere Rendern und Aktualisieren - korrekt funktionieren kann. Es hat die Option, ein fester Zeitschritt zu sein (unfixed[update/render] ist falsch) oder nicht.

Das Problem tritt auf, wenn Breakpoint-basiertes Debugging an einem beliebigen Punkt der Anwendung ausgeführt wird, da es eine Stoppuhr verwendet, um herauszufinden, wie viel Echtzeit verstrichen ist (zum Zweck von Physik und Animation mit realistischer Geschwindigkeit) basierend darauf, wie viele Frames der Computer ausgeben kann).

Es sieht (grob) wie diese, mit mehrere Stoppuhren für jeden ‚Teil‘ der Anwendung Schleife, die, wie viel Zeit wissen muss, hat sich seit dem ‚Teil‘ bestanden zuletzt aufgetretenen:

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(); 

    } 
} 

Einige Informationen über die Variablen:

updatestopwatch ist ein Stopwatch für die Zeit außerhalb der Funktion Update() ausgegeben,

renderstopwatch ist ein Stopwatch für die Zeit außerhalb der Render() Funktion ausgegeben, und

gamestopwatch ist ein Stopwatch für die gesamte verstrichene Zeit der Simulation/Spiel selbst.

Das Problem tritt auf, wenn ich irgendwo in der Anwendung debuggen. Da die Stoppuhren Echtzeit messen, wird die Simulation von jedem Breakpoint-basierten Debugging komplett abgeworfen, da die Stoppuhren die Zeit zählen, egal ob ich die Anwendung debugge oder nicht. Ich verwende die Stoppuhren nicht, um die Leistung zu messen: Ich verwende sie, um die Zeit zwischen dem erneuten Auftreten von Update, Render und anderen Ereignissen wie den oben dargestellten zu verfolgen. Das wird sehr frustrierend, wenn ich einen Breakpoint spalte und einen Fehler in Update() analysiere und behebe, aber dann ist die Render() -Zeit so komplett ausgeschaltet, dass jede Anzeige der Ergebnisse der Simulation rachsüchtig ins Gesicht gekickt wird.

Das heißt, wenn ich mit dem Debuggen ganz aufhöre, ist es offensichtlich kein Problem, aber ich habe viel Entwicklungsarbeit zu tun, und ich werde für eine lange Zeit debuggen, also nur so tun, dass dies nicht unbequem ist wird leider nicht funktionieren. = [

Ich schaute auf Performance Counters, aber ich kann mich nicht darum kümmern, wie man sie im Kontext dessen, was ich versuche, zum Laufen bringt: Render and Update kann jede beliebige Menge enthalten Code (sie sind spezifisch für was auch immer Simulation läuft auf dieser while Schleife), was bedeutet, dass ich nicht kontinuierlich eine PerformanceCounter.Increment() für die einzelnen Komponenten der Schleife tun kann.

Ich werde stöbern bei System.Diagnostics und anderen .NET-Namespaces, aber bisher habe ich Blanks auf, wie man einfach die Zeit in den beigefügten Debugger "ignoriert" ...

Wer hat irgendwelche Ideen oder Einblicke?

[[EDITS 5x] Korrigierte Rechtschreibfehler und sichergestellt, dass die Formatierung für alles korrekt war. Das tut mir leid.

]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Original, weniger klare Frage]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ich habe eine konstante Schleife läuft in einer C# -Anwendung, die ich Debugging die ganze Zeit. Ich verwende derzeit eine Stoppuhr, aber ich könnte jeden anderen Mechanismus verwenden, um die verstreichende Zeit zu verfolgen. Mein Problem beginnt, wenn ich Dinge wie die Verwendung von Haltepunkten irgendwo in dieser Schleife (eingeschlossen in einer typischen while (true) { ... }:

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

misst die Zeit selbst in Ordnung, aber es misst tatsächliche Echtzeit - einschließlich jeden Mal, wenn ich das Debuggen ausgegeben. Das heißt, wenn ich 17 Sekunden nach updatestopwatch.Reset() herumstochere, wird dies in meine Schleife eingefügt und - für mindestens 1 Wiederholung dieser Schleife - muss ich mich mit der zusätzlichen Zeit befassen, die ich in Echtzeit verbracht habe, indem ich in all meine Berechnungen einbezogen habe .

Gibt es irgendeine Möglichkeit, die ich in den Debugger einhaken kann, um zu wissen, wann es die Anwendung einfriert, damit ich zählen kann er-messen Sie die Zeit und subtrahieren Sie sie entsprechend? Als getaggt benutze ich .NET und C#, aber alles, was mit Visual Studio zusammenhängt, könnte mir helfen, in die richtige Richtung zu gehen.

[EDIT] Um weitere Informationen bereitzustellen, verwende ich mehrere Stoppuhren (für Update, Rendering und einige andere Ereignisse alle in einer anderen Nachrichtenwarteschlange). Wenn ich innerhalb von Update() oder in einem anderen Teil der Anwendung einen Haltepunkt festlege, messen die Stoppuhren genau die zwischen ihnen verbrachte Echtzeit. Dies beinhaltet die Zeit, die ich mit der Fehlersuche in verschiedenen, nicht miteinander in Beziehung stehenden Komponenten meiner Anwendung verbringe, die nach Update() oder Render() oder Input() usw. heißen. Offensichtlich wird das Timing der Simulation (gesteuert durch den GameTime-Parameter, der in die Toplevel-Funktionen Update, Render usw. übergeben wird) nicht ausgeführt richtig funktionieren, wenn, selbst wenn die CPU nur 13 ms dauerte, um die Update-Funktion zu beenden, ich 13 extra Sekunden Debugging ausgeben (Blick auf Variablen und dann Weiter mit der Simulation); Das Problem ist, dass ich sehen werde die anderen Stoppuhren plötzlich 13 extra Sekunden der Zeit. Wenn es immer noch keinen Sinn ergibt, werde ich wieder hineinspielen.

Answer 1

Verwenden Sie stattdessen Leistungsindikatoren. Die Prozess-CPU-Zeit sollte einen guten Indikator liefern (aber nicht so genau wie eine Echtzeit-Stoppuhr) und sollte das Debugging nicht beeinträchtigen.

Answer 2

Eine mögliche Lösung hierfür wäre, Ihre Locals (oder die Daten, die Sie versuchen zu debuggen) mit Debug.WriteLine() in die Ausgabe schreiben.