Jeśli profiler nie jest odpowiedzią, jakie mamy inne możliwości?

• Pobieranie Próbek powinno być nieskorelowane ze stanem programu.
  Oznacza to, że dzieje się to w naprawdę losowym czasie, niezależnie od tego, czy program znajduje się we I/O (z wyjątkiem danych wejściowych użytkownika), czy w GC, czy w ciasnej pętli procesora, czy cokolwiek innego.

• Próbkowanie powinno odczytać stos wywołań funkcji ,
  aby określić, które stwierdzenia były "aktywne" w momencie próby. Powodem jest to, że każda strona wywołująca (punkt, w którym funkcja jest called) ma koszt procentowy równy ułamkowi czasu, jaki znajduje się na stosie. (Uwaga: artykuł dotyczy wyłącznie czasu własnego, ignorując ogromny wpływ możliwych do uniknięcia wywołań funkcji w dużym oprogramowaniu. W rzeczywistości, powodem oryginału gprof była pomoc w znalezieniu tych połączeń.)

• Raportowanie powinno pokazywać procent według linii (nie według funkcji).
  Jeśli zostanie zidentyfikowana funkcja "gorąca", nadal trzeba upolować w niej "gorące" linie kodu odpowiadające czas. Ta informacja jest w próbkach ! Po co to ukrywać?

Omyłką niemal uniwersalną (którą dzieli papier) jest zbyt duża dbałość o dokładność pomiaru , a za mało o dokładność miejsca . Na przykład, Oto przykład strojenia wydajności w którym zidentyfikowano i naprawiono szereg problemów z wydajnością, co skutkowało 43-krotnym przyspieszeniem. Nie było konieczne dokładne poznanie wielkości każdego problem przed naprawą, ale znać jego lokalizację. Zjawisko dostrajania wydajności polega na tym, że naprawienie jednego problemu, poprzez skrócenie czasu, powiększa odsetek pozostałych problemów, dzięki czemu są łatwiejsze do znalezienia. Tak długo, jak Każdy problem zostanie znaleziony i naprawiony, postęp jest w kierunku celu znalezienia i naprawienia wszystkich problemów. Nie jest konieczne, aby naprawić je w porządku malejącej wielkości, ale ważne jest, aby je wskazać.

Na temat dokładności statystycznej pomiar, jeśli punkt wywoławczy znajduje się na stosie jakiś procent czasu F (jak 20%), A N(jak 100) próbki w czasie losowym są pobierane, to liczba próbek, które pokazują punkt wywoławczy jest rozkład dwumianowy, ze średnią = NF = 20, odchylenie standardowe = sqrt(NF (1-F)) = sqrt (16) = 4. Więc procent próbek, które pokazują, że będzie 20% + / - 4%. Czy to prawda? Nie bardzo, ale czy problem został znaleziony? Dokładnie.

W rzeczywistości, im większy problem, jeśli chodzi o procent, tym mniej próbek są potrzebne, aby go zlokalizować. Na przykład, jeśli pobrane zostaną 3 próbki, a na 2 z nich pojawi się punkt wywoławczy, najprawdopodobniej będzie to bardzo kosztowne. (W szczególności następuje Dystrybucja beta. Jeśli wygenerujesz 4 jednorodne 0,1 liczby losowe i posortujesz je, rozkład trzeciego jest rozkładem kosztów dla tego punktu wywoławczego. To wredne jest (2+1)/(3+2) = 0.6, więc to jest oczekiwane oszczędności, biorąc pod uwagę te próbki.) Wstawiony: a czynnik speedup jaki otrzymujesz jest regulowany przez inną dystrybucję, BetaPrime, ijego średnia wynosi 4. Więc jeśli weźmiesz 3 próbki, zobaczysz problem na 2 z nich i wyeliminujesz ten problem, średnio stworzysz program cztery razy szybciej.

Zastrzeżenie - artykuł nie odwołał się do mojego artykułu: Dunlavey, "strojenie wydajności z kosztem na poziomie instrukcji pochodzącym z próbkowania stosu połączeń", ACM SIGPLAN Notices 42, 8 (Sierpień 2007), s. 4-8.