Profiler – narzędzie dewelopera cz. II

27/01/2023

Dziś kontynuujemy wykorzystanie narzędzia Profiler Control do przetestowania kodu naszej aplikacji. Weźmy np. prosty poniższy przykład CustReport.p który wyświetla w pętli podstawowe pola z tablicy Customer,

DEFINE VARIABLE dOrdervalue AS DECIMAL NO-UNDO.

FOR EACH customer WHERE custnum < 100:
   dOrdervalue = 0.
   IF custnum < 40 THEN 
      RUN ordervalue.p (custnum, OUTPUT dOrdervalue).
   
   DISP custnum name dOrdervalue.

END.

a dla części iteracji uruchamia dodatkową procedurę ordervalue.p zliczającą sumę zamówień klienta.

DEF INPUT PARAM icustnum AS INTEGER.
DEF OUTPUT PARAM dordval AS DECIMAL.

FIND customer WHERE customer.custnum = icustnum.

FOR EACH order OF customer, EACH orderline OF order:
   dordval += price * qty.
END.

Po uruchomieniu Profilera zostanie wygenerowany plik typu .out. Jeśli spróbujemy go otworzyć przy pomocy przycisku VIEW z panelu narzędzia, dostaniemy komunikat o błędzie: Cannot load data. Don’t know how to load data for version 3.
Otwórzmy plik zwykłym edytorem tekstowym, np. Notepad++. Na pierwszej pozycji znajduje się nr wersji a potem data. Zmieniamy wartość nr wersji 3 na 1.
Zobaczmy przy okazji, że plik ten zawiera informacje generowane podczas inicjalizacji sesji oraz dane niezbędne do analizy przy pomocy Viewera.

Po naciśnięciu VIEW zobaczymy poniższy ekran.

Profiler udostępnia statystyki dotyczące działania programu. Dane te są podzielone według bloków i poszczególnych linii kodu. Każdy blok reprezentuje aktualną procedurę, procedurę wewnętrzną lub funkcję. W górnym pasku, po lewej stronie możemy wybrać zarejestrowaną sesję. Obszar 1 zawiera następujące informacje:

Code Block: nazwa wewnętrznej procedury lub funkcji, tryger interfejsu użytkownika i nazwa programu
Calls To: liczba wykonań tego bloku kodu
Avg Time: średni czas w sekundach potrzebny do wykonania tego bloku kodu
Tot Time: całkowity czas w sekundach potrzebny do wykonania tego bloku kodu
%Session: procent całej sesji wykorzystany przez ten blok kodu w porównaniu z innymi blokami kodu
Cum Time: całkowity czas potrzebny do wykonania tego bloku kodu oprócz całkowitego czasu wszystkich bloków kodu wywołanych przez ten blok.

Obszar 3 zawiera informacje dot. linii kodu:

Line: numer linii w wybranym programie
Exec Count: liczba wykonań tej linii kodu
Avg Exec: średni czas wykonania tej linii kodu w sekundach
Tot Time: całkowity czas w sekundach potrzebny do wykonania tej linii kodu
Cum Time: całkowity czas w sekundach, jaki zajęło wykonanie tego wiersza kodu, a także wszelkich bloków kodu, wywołanych przez tę linię. UWAGA: ta liczba będzie się różnić od Tot Time tylko wtedy, gdy linia kodu jest instrukcją uruchomienia procedury lub wywołania funkcji.
Pozostałe pola nie są używane.

Wreszcie obszar 2.
Calling Code Block oraz Called Code Block umożliwiają nawigację między różnymi sekcjami kodu poprzez dwukrotne kliknięcie wybranego wiersza.
Widzimy, że procedura ordervalue.p była wywołana 38 razy, co zajęło niecałe 4% czasu sesji.

Jeszcze jedna sprawa – na ekranie wyjściowym Profilera (pierwszy obraz w poprzednim artykule) widzimy po prawej stronie trzy pola wyboru: Listing, Coverage, Tracking.
Pierwsze służy do wygenerowania listingu, który będzie widoczny w Viewerze. Coverage służy do generowania dodatkowych danych dla procedur zewnętrznych, a Tracking do określenia filtra dla generowania danych tylko dla określonych procedur. Jeśli zaznaczymy Listing i ponownie uruchomimy sesję, na ekranie pojawi się listing programu, a wybór linii kodu a w browserze podświetli tę linię na listingu. Bardzo użyteczna funkcja.

Teraz trzeba już tylko przetestować własne procedury aby zorientować się w przydatności Profilera.
To jeszcze nie koniec. W następnym odcinku zobaczymy jak używać tego narzędzia w Developer Studio.

Development Profiler