P1: Jakich narzędzi używasz do profilowania kodu (profilowanie, a nie testowanie wydajności)?
P2: Jak długo pozwalasz na działanie kodu (statystyki: ile kroków czasu)?
P3: Jak duże są przypadki (jeśli sprawa mieści się w pamięci podręcznej, solver jest o rząd wielkości szybszy, ale wtedy przegapię procesy związane z pamięcią)?
Oto przykład tego, jak to robię.
Oddzielam testy porównawcze (sprawdzanie, jak długo to potrwa) od profilowania (identyfikowanie, jak przyspieszyć). Nie jest ważne, aby profiler był szybki. Ważne jest, aby informował o tym, co naprawić.
Nie podoba mi się nawet słowo „profilowanie”, ponieważ wyczarowuje obraz coś w rodzaju histogramu, w którym dla każdej procedury istnieje pasek kosztów, lub „wąskie gardło”, ponieważ oznacza, że w kodzie jest tylko trochę miejsca, które musi być naprawiony. Obie te rzeczy oznaczają pewien czas i statystyki, dla których, jak zakładasz, ważna jest dokładność. Nie warto rezygnować z wglądu w dokładność pomiaru czasu.
Zastosowanie metody I jest przypadkowe zatrzymywanie, a tam pełne studium przypadku i pokaz slajdów tutaj . Częścią światopoglądu wąskiego gardła profilera jest to, że jeśli niczego nie znajdziesz, nic nie można znaleźć, a jeśli coś znajdziesz i uzyskasz określony procent przyspieszenia, ogłaszasz zwycięstwo i rezygnujesz. Fani Profiler prawie nigdy nie mówią, ile przyspieszają, a reklamy pokazują tylko sztucznie wymyślone problemy, które można łatwo znaleźć. Losowe wstrzymywanie powoduje znalezienie problemów, czy są one łatwe, czy trudne. Następnie naprawienie jednego problemu ujawnia inne, dzięki czemu proces można powtórzyć, aby uzyskać złożone przyspieszenie.
Z mojego doświadczenia wynikającego z wielu przykładów, oto jak to wygląda: mogę znaleźć jeden problem (przez losowe wstrzymanie) i naprawić go, uzyskując przyspieszenie o pewien procent, powiedzmy 30% lub 1,3x. Następnie mogę to zrobić ponownie, znaleźć inny problem i rozwiązać go, otrzymując kolejne przyspieszenie, może mniej niż 30%, może więcej. Potem mogę to zrobić wiele razy, dopóki naprawdę nie znajdę nic innego do naprawienia. Ostateczny współczynnik przyspieszenia jest działającym iloczynem poszczególnych czynników i może być niesamowicie duży - w niektórych przypadkach rzędu wielkości.
WSTAWIONO: Aby zilustrować ten ostatni punkt. Jest to szczegółowy przykład tutaj , z pokazu slajdów i wszystkich plików, pokazując, jak przyspieszenie od 730X został osiągnięty w serii problemowych przeprowadzek. Pierwsza wersja zajęła 2700 mikrosekund na jednostkę pracy. Problem A został usunięty, co skróciło czas do 1800 i zwiększyło odsetek pozostałych problemów o 1,5x (2700/1800). Następnie B został usunięty. Proces ten trwał przez sześć iteracji, co spowodowało przyspieszenie prawie 3 rzędów wielkości. Ale technika profilowania musi być naprawdę skuteczna, ponieważ jeśli którykolwiek z tych problemów nie zostanie znaleziony, tj. Jeśli dojdziesz do punktu, w którym błędnie myślisz, że nic więcej nie można zrobić, proces zatrzymuje się.
WSTAWIONO: Innymi słowy, oto wykres współczynnika całkowitego przyspieszenia po usunięciu kolejnych problemów:
Tak więc w pierwszym kwartale do przeprowadzenia testu porównawczego wystarczy prosty licznik czasu. Do „profilowania” używam losowego wstrzymywania.
Q2: Daję mu wystarczającą ilość pracy (lub po prostu owinąć pętlę), aby działał wystarczająco długo, aby zatrzymać.
P3: Zapewnij realistycznie duże obciążenie pracą, aby nie przegapić problemów z pamięcią podręczną. Będą one wyświetlane jako próbki w kodzie wykonującym pobieranie pamięci.