Używam VS2008, w normalnym rozwiązaniu średniej wielkości.Debugowanie czasami bardzo powolne
Czasami krokowanie debugowania staje się bardzo powolne. Kłódka jest renderowana na każdej karcie pliku dla każdego "kroku" (F10/F11), a na każdy krok może zająć do dwóch sekund. To sprawia, że debugowanie jest bardzo denerwujące i powolne. Czy ktoś widział ten problem?
Tak, Visual Studio jest bardzo powolny w debugowania Istnieje wiele dodatkowych kroków (oprócz wyłączenia ustawienia "Włącz ocenę właściwości"), które możesz podjąć, aby przyspieszyć proces. Zasadniczo wymaga to ogromnej ilości pamięci RAM, więc pomożemy wykonać kilka rzeczy za darmo.
Przejdź do preferencji Visual Studio. Poszukaj wszystkich opcji związanych z animowaniem menu i tak dalej. Te mają tendencję do bycia intensywnymi czasami, ale nie są specyficzne dla debugowania, ponieważ zazwyczaj nie otwierasz menu, wydaje się, że pomaga.
Na komputerze, jeśli klikniesz prawym przyciskiem myszy na moim komputerze. Przejdź do karty zaawansowanej i wydajności. Jeśli dostosujesz swój komputer, by uzyskać najlepszą wydajność, przyspieszy to. Usuwa wszelkie fajne style na komputerze, ale zwolni trochę pamięci, której potrzebujesz.
Zamknij wszystkie niepotrzebne programy. Im więcej pamięci możesz dać Visual Studio, tym lepiej się zachowa.
@kaze Mam profilowane wiele spowolnień Visual Studio i nigdy nie widziałem, aby były znaczącym czynnikiem. 1) Menu nie powinny się znacząco animować podczas debugowania, szczególnie jeśli używasz skrótów klawiaturowych do pojedynczego kroku. 2) Każda rozsądnie wydajna maszyna (wystarczająca pamięć, procesor, rozsądny procesor graficzny) może obsłużyć domyślne ustawienia wydajności. 3) Ostatnia wskazówka ma zastosowanie tylko wtedy, gdy komputer nie ma wystarczającej ilości pamięci. Pokaż wątki w Źródło i nadmierne punkty przerwania mogą powodować, że program Visual Studio będzie wolniej uruchamiać rzędy wielkości. Odpowiedzi sugerujące te są znacznie bardziej przydatne. –
Spróbuj wyłączyć „Włącz ocenę właściwości ...” ustawienie w opcjach debugger powinien uczynić debugowania znacznie szybciej (czytaj więcej: Fix: Make Debugging Faster with Visual Studio):
Here's a link to some guidance on Mike Stahl's MSDN blog, w odniesieniu do rozwiązania spowolnienie debugera
natknąłem tego powodu wartości graniczne warunkowe w mojej aplikacji hotspot zabił moją wydajność debugowania. Osobiste BKM: rozwiązuj potencjalne problemy z wydajnością przed wyjściem na noc, ponieważ możesz nie pamiętać ich rano.
Zauważyłem w VS 2008, że jeśli masz przycisk "Pokaż wątki w źródle" wybrany na pasku narzędzi debugowania, to krokowanie może być co najmniej 10 razy wolniejsze.
Zauważyłem również, że jeśli twoja aplikacja wymaga długiego czasu, aby rozpocząć w trybie debugowania, można to rozwiązać, jeśli po prostu "Usuń wszystkie punkty przerwania" w menu Debuguj. To rozwiązało dla mnie irytujący problem, mimo że miałem tylko garstkę punktów przerwania ustawionych w tym czasie.
Silas
Wyłącz Pokaż wątki w źródle w Visual Studio. i Zamknij okno śledzenia stosu połączeń.
+1 Pracowałem dla mnie :). – MichaelMocko
Oprócz wszystkich wyżej wymienionych zagadnień.
Zakładka "Demontaż" (otwarta w tle) spowalnia debugowanie o 1-2 sekundy na krok. (Nie jestem pewien, czy to zawsze tak się dzieje).
To był mój przypadek, wyłączenie oceny nieruchomości pomogło, ale samo zamknięcie okien demontażu spowodowało, że debugowanie było znacznie szybsze (od około 3 sekund do prawie jednej chwili) ... dzięki! – Martin
Miałem ten sam problem, zwłaszcza podczas debugowania aplikacji z wieloma wątkami.
Zostało to spowodowane przez funkcję "Pokaż wątki w źródle".
Zobacz poniższy link do szczegółów:
Code Project: Show threads in source
Visual Studio Single Step Performance Fixes
Po wyłączeniu tej funkcji, problem został rozwiązany.
Istnieje wiele rzeczy, które mogą powodować spowolnienie Visual Studio. Nadmierne punkty przerwania i Pokaż wątki w źródle są prawdopodobnie tymi dwoma najpowszechniejszymi, ale nie obchodzi cię, co jest najczęstsze, zależy ci na tym, co powoduje, że Visual Studio zwolni dla * Ciebie *.
Jeśli więc usunięcie punktów przerwania i wyłączenie Pokaż wątki w źródle nie działa, musisz profilować Visual Studio. Dzięki temu możesz znaleźć problemy z wydajnością, które są unikalne w Twojej sytuacji. Wyjaśnienie, jak to (co rozwiązane dwa oddzielne problemy z wydajnością Visual Studio) zrobić, można znaleźć tutaj:
http://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/
Więcej dochodzeniu przyczyn problemów z wydajnością w kodzie innych ludzi są opisane tutaj:
http://randomascii.wordpress.com/category/investigative-reporting/
Inną przyczyną powolności jednego kroku jest użycie Intellitrace (dostępne tylko w wersji Ultimate). Aby go wyłączyć, Narzędzia | Opcje | IntelliTrace. Odznacz opcję Włącz IntelliTrace.
Propozycja "Pokaż wątki w źródle" nie pomogła.
Ale naprawiłem to przez włączenie Narzędzia: Opcje: Debugowanie: Ogólne -> "Wymagaj plików źródłowych, aby dokładnie pasowały do oryginalnej wersji".
Moje początkowo odznaczono, ale po zmianie, przejście przez kod w VS2008 powróciło do normalnej prędkości.
wyczyść wszystkie wpisy w oknie oglądania.
Dziękuję za odpowiedź, ale czy mógłbyś podać dodatkowe informacje na temat tego rozwiązania? Dlaczego miałby rozwiązać problem, w jaki sposób rozwiązałby problem itp. – Hiphop03199
Pomogło mi wyłączyć narzędzia diagnostyczne.
Narzędzia/Opcje/Debugging/Ogólne/Włącz narzędzi diagnostycznych
Visual Studio 2015 (wersja 14)
doświadczyłem tego problemu po włączeniu ".NET Framework źródłowy Stepping". Kroczenie było o wiele szybsze po wyłączeniu tego. Zwłaszcza włączenie opcji "Włącz tylko mój kod" (Options> Debugging> General) usunęło około połowy opóźnienia, którego doświadczałem.
Druga połowa została spowodowana przez załadowanie większej liczby symboli niż potrzebowałem (Opcje> Debugowanie> Symbole). W pewnym momencie potrzebowałem zdefiniowanych lokalizacji symboli, ale już ich nie było, więc udało mi się odznaczyć je wszystkie i kliknąć "Empty Symbol Cache". Jeśli masz na liście _NT_SYMBOL_PATH, oznacza to, że masz zdefiniowane to ustawienie środowiska, a Visual Studio nie pozwoli ci odznaczyć go. Musisz usunąć ustawienie. Więcej informacji o ustawieniach symboli (https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/05/understanding-symbol-files-and-visual-studios-symbol-settings/)
Miałem ten sam problem, usunąłem wszystkie moje zmienne zegarki i bardzo mi pomogło!Ponieważ każdy krok podczas debugowania powoduje przeładowanie wszystkich zegarków i wymaga czasu ...
Rozwiązanie: Z menu Debuguj wybierz system Windows, a następnie Watch i kliknij Watch1, Watch2, Watch3 lub Watch4. Pojawi się menu i kliknij je prawym przyciskiem myszy, aby je wszystkie wyczyścić.
Jeśli masz skaner antywirusowy (z włączonymi skanami w czasie rzeczywistym), sprawdź, czy C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe * jest wykluczony ze skanowania ze skanowania.
W moim przypadku debugowanie stało się bardzo powolne po wprowadzeniu na rynek nowego skanera antywirusowego. Po pewnym czasie dowiedzieliśmy się, że przyczyną problemu był skan msvsmon.exe w czasie rzeczywistym.
* Modyfikuj ścieżkę zgodnie z folderem instalacyjnym
Pytanie stare jak brud, ale wciąż aktualne, ponieważ przydarzyło mi się. W moim przypadku odpowiedź polegała po prostu na tym, aby okno "Stos połączeń" było nieaktywne. Zazwyczaj jest on ułożony razem z "Auto", "Locals" i "Watch", więc po prostu kliknij jeden z nich, aby umieścić "Call Stack" w tle. – JPNotADragon
wrt @ Odpowiedź JPNotADragona: dezaktywowanie okna stosu wywołań (tj. Przejście do innego okna) również w magiczny sposób rozwiązało moje problemy z perf w trakcie debugowania (krok, a także sprawdzanie zmiennych). Co więcej, problemy z perf nie powróciły po ** re ** aktywacji okna stosu wywołań. – bvgheluwe