Ich benutze VS2008, in einer normalen mittelgroßen Lösung.Debugging manchmal sehr langsam
Manchmal wird das Debug-Stepping sehr langsam. Ein Vorhängeschloss wird für jeden "Schritt" (F10/F11) auf jeder Datei-Registerkarte gerendert, und es kann für jeden Schritt bis zu zwei Sekunden dauern. Das macht das Debugging sehr nervig und langsam. Hat jemand dieses Problem gesehen?
Ja, Visual Studio ist extrem langsam bei Debugging Manchmal gibt es eine Reihe zusätzlicher Schritte (zusätzlich zur Deaktivierung der Einstellung "Eigenschaftenbewertung aktivieren"), die Sie ergreifen können, um den Prozess zu beschleunigen. Im Wesentlichen erfordert es enorme Mengen an RAM, so ein paar Dinge zu tun, um das zu befreien, wird helfen.
Gehen Sie in die Einstellungen von Visual Studio. Suchen Sie nach allen Optionen zum Animieren von Menüs und so weiter. Diese haben eine Tendenz, zuweilen intensiv zu sein, während sie nicht spezifisch für das Debuggen sind, da sie normalerweise keine Menüs öffnen, scheint es zu helfen.
Auf dem Computer selbst, wenn Sie mit der rechten Maustaste auf meinen Computer klicken. Gehe auf die Registerkarte Erweitert und unter Leistung. Wenn Sie Ihren Computer für die beste Leistung anpassen, beschleunigt dies die Dinge. Es wird alle schönen Stile auf Ihrem Computer los, aber es wird etwas von dem Speicher freigeben, den Sie wollen.
Schließen Sie alle nicht benötigten Programme. Je mehr Speicher Sie Visual Studio geben können, desto besser wird es sich verhalten.
@kaze Ich habe viele Visual Studio Verlangsamungen profiliert und ich habe nie gesehen, dass diese ein signifikanter Faktor sind. 1) Menüs sollten beim Debuggen nicht signifikant animiert werden, insbesondere wenn Sie Tastaturkürzel für Einzelschritte verwenden. 2) Jeder ausreichend leistungsfähige Rechner (genügend Speicher, CPU, vernünftige GPU) kann die Standard-Leistungseinstellungen verarbeiten. 3) Der letzte Tipp gilt nur, wenn Ihr Computer nicht genügend Speicher hat. Show Threads in Source und exzessive Haltepunkte können dazu führen, dass Visual Studio Größenordnungen langsamer ausführt. Die Antworten, die diese vorschlagen, sind viel benutzerfreundlicher. –
Versuchen Sie, die „Enable-Eigenschaft-Bewertung ...“ -Einstellung in Debugger-Optionen, sollte es dem Debuggen viel schneller (lesen Sie mehr: Fix: Make Debugging Faster with Visual Studio): Ausschalten
Here's a link to some guidance on Mike Stahl's MSDN blog in Bezug Debugger Verlangsamungen zur Lösung
ich über diese lief, weil bedingte Haltepunkte in hotspot meine App meine Debug-Performance getötet. Persönliches BKM: Lösen Sie potenzielle Leistungsprobleme, bevor Sie in die Nacht fahren, denn Sie erinnern sich vielleicht nicht mehr am Morgen.
Ich habe in VS 2008 festgestellt, dass, wenn Sie die Schaltfläche "Threads in Quelle anzeigen" in der Debug-Symbolleiste ausgewählt haben, dass Schritt kann mindestens 10 mal langsamer sein.
Ich habe auch bemerkt, dass, wenn Ihre Anwendung lange im Debug-Modus startet, dass dies gelöst werden kann, wenn Sie einfach "Delete All Breakpoints" im Menü Debuggen. Dies löste ein lästiges Problem für mich, obwohl ich zu diesem Zeitpunkt nur eine Handvoll Breakpoints gesetzt hatte.
Silas
Disable Zeige Themen in Quelle in Visual Studio. und schließen Sie das Aufruf-Stack-Trace-Fenster.
+1 Arbeitete für mich :). – MichaelMocko
Zusätzlich zu allen oben genannten Themen.
Eine Registerkarte "Disassembly" (im Hintergrund geöffnet) verlangsamt das Debugging um 1-2 Sek. Pro Schritt. (Nicht sicher, ob es immer so passiert).
Das war mein Fall, das Deaktivieren der Eigenschaftsauswertung half, aber das Schließen der Disassemblierungsfenster machte das Debuggen viel schneller (von ungefähr 3 Sekunden bis zu einem Augenblick) ... Danke! – Martin
Ich hatte das gleiche Problem, vor allem beim Debuggen von Apps mit vielen Threads.
Es wurde durch die Funktion "Show threads in source" verursacht.
Siehe den folgenden Link für Details:
Code Project: Show threads in source
Visual Studio Single Step Performance Fixes
Nach Deaktivieren dieser Funktion Problem behoben wurde.
Es gibt viele Dinge, die dazu führen können, dass Visual Studio langsam ist. Übermäßige Breakpoints und Show Threads in Source sind wahrscheinlich die zwei häufigsten, aber es ist Ihnen egal, was am häufigsten vorkommt. Sie interessieren sich dafür, dass Visual Studio langsam für * you *.
Wenn also das Löschen von Haltepunkten und das Deaktivieren von Threads in Source anzeigen nicht funktioniert, müssen Sie Visual Studio profilieren. Dadurch können Sie Leistungsprobleme finden, die für Ihre Situation einzigartig sind. Eine Erklärung, wie diese (die gelöst zwei separate Visual Studio Performance-Probleme) zu tun, sind hier zu finden:
http://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/
Weitere Untersuchungen von Performance-Problemen in Code anderer Leute sind hier aufgeführt:
http://randomascii.wordpress.com/category/investigative-reporting/
Eine weitere Ursache für die Langsamkeit in einem Schritt ist die Verwendung von Intellitrace (nur in Ultimate verfügbar). Um es zu deaktivieren, wählen Sie Extras | Optionen | IntelliTrace. Deaktivieren Sie die Option IntelliTrace aktivieren.
Der Vorschlag "Threads in Quelle anzeigen" hat nicht geholfen.
Aber ich habe es behoben, indem Sie Extras: Optionen: Debuggen: Allgemein -> "Erfordern Quelldateien, die genau mit der ursprünglichen Version übereinstimmen".
Mine wurde zunächst deaktiviert, aber nachdem es geändert wurde, geht der Code in VS2008 wieder auf normale Geschwindigkeit zurück.
löschen Sie alle Einträge im Überwachungsfenster.
Vielen Dank für Ihre Antwort, aber könnten Sie bitte einen zusätzlichen Einblick in diese Lösung geben? Warum sollte es das Problem lösen, wie würde es das Problem lösen usw. – Hiphop03199
Was mir geholfen hat, war die Diagnose-Tools zu deaktivieren.
Tools/Options/Debugging/Allgemein/Aktivieren Diagnosetools
Visual Studio 2015 (14 Version)
ich dieses Problem erlebt nach ".NET Framework Source Stepping" ermöglicht. Stepping wurde nach dem Ausschalten viel schneller. Insbesondere hat das Zurücksetzen von "Nur Code aktivieren" (Optionen> Debugging> Allgemein) ungefähr die Hälfte der Verzögerung entfernt, die ich erlebt habe.
Die andere Hälfte wurde verursacht, indem mehr Symbole geladen wurden, als ich benötigte (Optionen> Debugging> Symbole). Irgendwann brauchte ich definierte Symbol-Orte, aber ich tat es nicht mehr, also konnte ich sie alle abwählen und auf "Empty Symbol Cache" klicken. Wenn Sie _NT_SYMBOL_PATH aufgelistet haben, bedeutet dies, dass Sie diese Umgebungseinstellung definiert haben, und Visual Studio lässt Sie nicht deaktivieren. Sie müssen die Einstellung entfernen. Mehr über Symboleinstellungen (https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/05/understanding-symbol-files-and-visual-studios-symbol-settings/)
Ich hatte das gleiche Problem, löschte alle meine variablen Uhren und es half sehr!Weil jeder Schritt während des Debuggens alle Uhren neu lädt und es Zeit braucht ...
Lösung: Wählen Sie im Menü Debug Windows, dann Uhr, und klicken Sie auf Watch1, Watch2, Watch3 oder Watch4. Das Menü erscheint und Sie können mit der rechten Maustaste darauf klicken, um alle zu löschen.
Wenn Sie einen Virenscanner haben (mit aktivierten Echtzeitscans), überprüfen Sie, ob C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe * aus dem Scan ausgeschlossen ist.
In meinem Fall wurde das Debugging nach der unternehmensweiten Einführung eines neuen Virenscanners sehr langsam. Nach einer Weile fanden wir heraus, dass der Echtzeit-Scan von msvsmon.exe der Schuldige war.
* ändern Sie den Pfad gemäß Ihrem Installationsordner
Frage alt wie Schmutz, aber immer noch relevant, da es gerade mir passiert ist. In meinem Fall bestand die Antwort einfach darin, sicherzustellen, dass das "Call Stack" -Fenster nicht aktiv war. Es ist normalerweise zusammen mit "Auto", "Locals" und "Watch" gestapelt, also klicke einfach auf eines davon, um "Call Stack" in den Hintergrund zu stellen. – JPNotADragon
wrt @ JPNotADragon's Antwort: das Deaktivieren des Call-Stack-Fensters (d. H. Das Wechseln zu einem anderen Fenster) löste auch meine Perf-Probleme während des Debuggens (schrittweise sowie das Untersuchen von Variablen) auf magische Weise. Was noch mehr ist, die Perf-Probleme sind nicht zurückgekommen, nachdem ** das ** Call-Stack-Fenster aktiviert wurde. – bvgheluwe