Visual Studio 2015–Diagnostic Tools

Nie dawno pojawił się VS 2015 CTP5 -  zachęcam do ściągnięcia.

VS 2015 posiada wiele nowych narzędzi pozwalających na diagnostykę i profilowanie aplikacji. Chcę poświęcić na to kilka wpisów, zaczynając dzisiaj od Diagnostic Tools.

Oczywiście wszystkie te udogodnienia były wcześniej dostępne w formie osobnych narzędzi typu Memory czy CPU profiler. Trend jednak jest taki, że Visual Studio z każdym wydaniem zawiera więcej narzędzi wbudowanych, które kiedyś były osiągalne wyłącznie różne profilery czy Resharper.  Wciąż oczywiście jest długa droga przed VS (zwłaszcza w przypadku Resharper), ale pomysł wbudowanych profilerów bardzo podoba mi się.

Okno diagnostic tools otwiera się automatycznie po rozpoczęciu debuggowania. Jest zatem uzupełnieniem klasycznych narzędzi diagnostycznych takich jak Output czy lista ze zmiennymi (Watch, Locals itp.).  Diagnostic Tools składa się z 3 elementów: Debugger Events, zużycie pamięci oraz zużycie procesora (CPU). Po uruchomieniu, okno prezentuje się następująco:

image

Pierwsza sekcja, Debugger events pokazuje zdarzenia takie jak wywołanie Debugger.Break czy odpalanie danego breakpoint’a. Innymi słowy, mamy tam informacje, co spowodowało zatrzymanie pracy i uruchomienie trybu debuggowania. Przyjrzyjmy się oknu Debugger w momencie, gdy zostanie wyrzucony wyjątek:

image

Całą historie zdarzeń mamy na wykresie, a mianowicie:

image

Screen został zrobiony na podstawie następującego kodu:

image

 

Czerwony romb oznacza wyjątek. Fioletowy pasek reprezentuje przerwanie wykonania aplikacji z powodu wyjątku, czerwony pasek oznacza odpalenie breakpoint’u, z kolei niebieski wywołanie Debugger.Break().

Jak widzimy wielkość pasku zależy od czasu. Pierwszy breakpoint został wykonany prawie natychmiast od czasu uruchomienia aplikacji, dlatego jest bardzo mały. Następnie są uruchamiane co 2 sekundy stąd są nieco większe. Najeżdżając kursorem na pasek, dostaniemy szczegóły:

image

Wykres jest interaktywny. Klikając na zdarzeniu w oknie debugger dostaniemy informacje o nim. Na przykład, klikając na niebieskim pasku, zobaczymy w oknie debugger następujące informacje:

image

Można również zaznaczyć kilka zdarzeń jednocześnie, zaznaczając kursorem przedział czasu, który nas interesuje:

image

image

Kolejne okno pozwoli nam monitorować całkowite zużycie pamięci w aplikacji. Bardzo wygodne, bo debuggując na bieżąco widzimy, czy coś złego nie dzieje się w aplikacji. Załóżmy, że mamy następujący kod:

int a = 0; Thread.Sleep(2000); int[] data = new int[100000000]; Thread.Sleep(2000); data = null; GC.Collect(); GC.WaitForFullGCComplete(); Thread.Sleep(2000); data = new int[10000000]; Thread.Sleep(2000); Debugger.Break();

Na początku deklarujemy jedną zmienną, potem dużą tablice, następnie ją zwalniamy i alokujemy nieco mniejszą. Na wykresie zobaczymy zatem następujące dane:

image

 

Pierwsze 2 sekundy to deklaracja tylko jednej zmiennej, następnie tworzymy dużą tablicę zatem zużycie pamięci rośnie. Kolejna linia kodu usuwa tablicę z pamięci, stąd następne dwie sekundy to znów niskie zużycie pamięci. Ostatni fragment to alokacja małej tablicy i widzimy wyraźnie, że zużycie trochę wzrosło. Oczywiście jest to całkowite zużycie pamięci, a nie tylko zmiennych, które sami tworzymy.

Ostatnie okno, które chciałem pokazać to po prostu zużycie CPU:

image

Wykres, jak każdy poprzedni jest interaktywny i najeżdżając kursorem dostaniemy dodatkowe informacje.

Jak wspomniałem, nie są to żadne nowości, ale ze względu na to, że są zintegrowane z VS i tak łatwo dostępne, debugging aplikacji pozwala na bieżąco monitorować, co dzieje się z kodem.

Leave a Reply

Your email address will not be published.