Można by użyć profilera, ale dlaczego nie zatrzymać programu? [zamknięte]

Ponieważ czasami to działa, a czasami daje całkowicie błędne odpowiedzi. Profiler ma dużo lepsze wyniki w znalezieniu właściwej odpowiedzi i zwykle dociera tam szybciej.

Robienie tego ręcznie nie może być tak naprawdę nazywane "szybkim" lub "skutecznym", ale istnieje kilka narzędzi do profilowania, które robią to automatycznie; znane również jako profilowanie statystyczne .

Próbkowanie Callstack jest bardzo przydatną techniką profilowania, szczególnie gdy patrzymy na dużą, skomplikowaną bazę kodową, która może spędzać czas w dowolnej liczbie miejsc. Ma tę zaletę, że mierzy zużycie procesora przez zegar ścienny, co jest ważne dla interaktywności, a uzyskanie pakietów wywołań z każdą próbką pozwala zobaczyć Dlaczego funkcja jest wywoływana. Używam go często, ale używam do tego zautomatyzowanych narzędzi, takich jak Luke Stackwalker i OProfile i różne rzeczy dostarczane przez sprzedawców sprzętu.

Powodem, dla którego wolę zautomatyzowane narzędzia niż ręczne pobieranie próbek do pracy, którą wykonuję, jest moc statystyczna . Ręczne pobieranie dziesięciu próbek jest w porządku, gdy masz jedną funkcję zajmującą 40% czasu trwania, ponieważ średnio dostaniesz w niej cztery próbki i zawsze co najmniej jedną. Ale potrzebujesz więcej próbek, gdy masz płaski profil, z setkami funkcji liścia, nie zajmując więcej niż 1,5% czasu pracy.

Powiedz, że masz jezioro z wiele różnych gatunków ryb. Jeśli 40% ryb w jeziorze to łosoś (i 60% "Wszystko inne"), wystarczy złapać dziesięć ryb, aby wiedzieć, że w jeziorze jest dużo łososia. Ale jeśli masz setki różnych gatunków ryb, a każdy z nich jest indywidualnie nie więcej niż 1%, musisz złapać dużo więcej niż dziesięć ryb, aby móc powiedzieć "to jezioro to 0,8% łososia i 0,6% pstrąga."

Podobnie w grach, nad którymi pracuję, istnieje kilka głównych systemów, z których każdy wywołuje dziesiątki funkcji w setkach różnych jednostek, a wszystko to dzieje się 60 razy na sekundę. Niektóre z tych funkcji' czasu leją się do zwykłych operacji (jak malloc), ale większość z nich nie, i w każdym razie nie ma pojedynczego liścia, który zajmuje więcej niż 1000 µs na klatkę.

Mogę spojrzeć na funkcje trunk i zobaczyć, "spędzamy 10% naszego czasu na kolizji", ale to nie jest zbyt pomocne: muszę dokładnie wiedzieć Gdzie w kolizji, więc wiem, które funkcje do ściśnij. Wystarczy "mniej kolizji" tylko do tej pory, zwłaszcza gdy oznacza to wyrzucanie funkcji. Wolałbym wiedzieć "wydajemy średnio 600 µs / klatka na chybienia pamięci podręcznej w wąskiej fazie oktree , ponieważ magiczny pocisk porusza się tak szybko i dotyka wielu komórek", ponieważ wtedy mogę wyśledzić dokładną poprawkę: albo lepsze drzewo, albo wolniejsze pociski.

Ręczne pobieranie próbek byłoby w porządku, gdyby było duże 20% grudki, powiedzmy, stricmp, ale z naszymi profilami to nie jest case. Zamiast tego mam setki funkcji, które muszę uzyskać od powiedzmy 0,6% klatki do 0,4% klatki. Muszę zgolić 10 µs co 50 µs funkcji, która jest wywoływana 300 razy na sekundę. Aby uzyskać taką precyzję, potrzebuję więcej próbek.

Ale w głębi serca to, co robi Luke Stackwalker, jest tym, co opisujesz: co milisekundę lub więcej, zatrzymuje program i rejestruje callstack(w tym dokładną instrukcję i numer linii IP ). Niektóre programy potrzebują tylko kilkudziesięciu tysiące próbek do użytecznego profilowania.

(rozmawialiśmy o tym wcześniej, oczywiście, ale pomyślałem, że to dobre miejsce, aby podsumować debatę.)

Jest różnica między rzeczami, które programiści faktycznie robią, a rzeczami, które polecają innym.

Znam wielu programistów (w tym mnie), którzy faktycznie używają tej metody. To tylko naprawdę pomaga znaleźć najbardziej oczywiste problemy z wydajnością, ale jest szybki i brudny i działa.

Ale tak naprawdę nie kazałbym innym programistom tego robić, ponieważ wyjaśnienie wszystkich zastrzeżeń zajęłoby mi zbyt dużo czasu. Zbyt łatwo jest wyciągnąć niedokładne wnioski w oparciu o tę metodę i istnieje wiele obszarów, w których po prostu nie działa w ogóle. (na przykład, metoda ta nie ujawnia żadnego kodu, który jest wyzwalany przez wejście użytkownika).

Więc podobnie jak używanie wykrywaczy kłamstw w sądzie, lub oświadczenie "goto", po prostu nie zalecamy, abyś to robił, mimo że wszystkie mają swoje zastosowania.

Jestem zaskoczony religijnym tonem po obu stronach.

Profilowanie jest świetne, a na pewno jest bardziej wyrafinowane i precyzyjne, gdy można to zrobić. Czasami nie możesz i miło jest mieć zaufane wsparcie. Technika pauzy jest jak ręczny śrubokręt, którego używasz, gdy elektronarzędzie jest zbyt daleko lub baterie się wyczerpały.

Oto krótka prawdziwa historia. Aplikacja (rodzaj zadania przetwarzania wsadowego) działała dobrze w produkcji przez sześć miesięcy, nagle operatorzy dzwonią do deweloperów, bo idzie "za wolno". Nie pozwolą nam dołączyć do produkcji profilera próbkowania! Musisz pracować z już zainstalowanymi narzędziami. Bez zatrzymywania procesu produkcyjnego, po prostu za pomocą Process Explorer , (który operatorzy już zainstalowali na maszynie) mogliśmy zobaczyć migawkę stosu wątku. Możesz spojrzeć na górę stosu, odrzucić go za pomocą klawisza enter i uzyskać kolejną migawkę za pomocą kolejnego kliknięcia myszy. Możesz łatwo pobrać próbkę co sekundę.

Nie trzeba długo sprawdzać, czy wierzchołek stosu znajduje się najczęściej w bibliotece klienta bazy danych DLL (oczekującej na bazę danych), czy w innej systemowej DLL (oczekującej na operację systemową), a właściwie w jakiejś metodzie samej aplikacji. W tym przypadku, jeśli dobrze pamiętam, szybko zauważyliśmy, że 8 razy na 10 aplikacja była w wywołaniu pliku DLL systemu odczytu lub zapisu pliku sieciowego. Na pewno Ostatnie "aktualizacje" miały zmieniono charakterystykę wydajności udziału plików. Bez szybkiego i brudnego i (usankcjonowanego przez administratora systemu) podejścia, aby zobaczyć, co aplikacja robi w produkcji , spędzilibyśmy znacznie więcej czasu próbując zmierzyć problem, niż go naprawić.

Z drugiej strony, gdy wymagania wydajności wykraczają poza "wystarczająco dobre", aby naprawdę naciskać kopertę, profiler staje się niezbędny, abyś mógł spróbować golić cykle ze wszystkich swoich / align = "center" bgcolor = "# e0ffe0 " / cesarz chin / / align = center / Nawet jeśli próbujesz utrzymać umiarkowane wymagania dotyczące wydajności podczas trwania projektu, kiedy możesz uzyskać odpowiednie narzędzia, które pomogą Ci zmierzyć i przetestować, a nawet zintegrować je z automatycznym procesem testowym, może to być fantastycznie pomocne.

Ale kiedy zasilanie jest wyłączone (że tak powiem) i baterie są martwe, to miło wiedzieć, jak używać tego ręcznego śrubokręta.

Więc bezpośrednia odpowiedź: wiesz, czego możesz się nauczyć wstrzymanie programu, ale nie bój się też precyzyjnych narzędzi. Najważniejsze wiedzieć, które zadania wymagają jakich narzędzi.

Jeśli weźmiemy pytanie " Dlaczego nie jest lepiej znany?"wtedy odpowiedź będzie subiektywna. Prawdopodobnie powodem, dla którego nie jest lepiej znany, jest to, że profilowanie zapewnia długoterminowe rozwiązanie, a nie aktualne rozwiązanie problemu. Nie jest skuteczny w przypadku aplikacji wielowątkowych i nie jest skuteczny w przypadku aplikacji takich jak gry, które spędzają znaczną część czasu na renderowaniu.

Ponadto, w aplikacjach z pojedynczym gwintem, jeśli masz metodę, której oczekujesz zużywaj najwięcej czasu uruchamiania i chcesz skrócić czas uruchamiania wszystkich innych metod, wtedy trudniej będzie określić, na których drugorzędnych metodach skoncentrować swoje wysiłki.

Twój proces profilowania jest akceptowalną metodą, która może i działa, ale profilowanie zapewnia więcej informacji i ma tę zaletę, że pokazuje bardziej szczegółowe ulepszenia wydajności i regresje.

Jeśli masz dobrze dobrany kod to możesz zbadać nie tylko jak długo dana metoda; możesz zobaczyć wszystkie metody.

Z profilowaniem:

• Po każdej zmianie można ponownie uruchomić scenariusz, aby określić stopień poprawy wydajności/regresji.

• Możesz profilować kod na różnych konfiguracjach sprzętowych, aby określić, czy twój sprzęt produkcyjny będzie wystarczający.

• Możesz profilować kod w scenariuszach obciążenia i testów warunków skrajnych, aby określić, w jaki sposób objętość informacje wpływają na wydajność

• Możesz ułatwić młodszym programistom wizualizację wpływu ich zmian w kodzie, ponieważ mogą oni zmienić profil kodu w ciągu sześciu miesięcy, gdy jesteś na plaży lub w pubie, lub oba te czynniki. Beach-pub, ftw.

Profilowanie ma większą wagę, ponieważ Kod przedsiębiorstwa powinien zawsze mieć pewien stopień profilowania ze względu na korzyści, jakie daje organizacji przez dłuższy okres czasu. Na im bardziej ważny jest kod, tym bardziej profilujesz i testujesz.

Twoje podejście jest poprawne i jest kolejnym elementem jest zestaw narzędzi programisty. To jest po prostu przeważa przez profilowanie.

Naciśnięcie przycisku pauzy podczas wykonywania programu w trybie "debug"może nie dostarczyć odpowiednich danych do przeprowadzenia optymalizacji wydajności. Mówiąc wprost, jest to prymitywna forma profilowania.

Jeśli musisz unikać używania profilera, lepszym rozwiązaniem jest użycie rejestratora, a następnie zastosowanie współczynnika spowolnienia do" zgadywania", gdzie jest prawdziwy problem. Profilery są jednak lepszymi narzędziami do zgadywania.

Powód, dla którego naciśnięcie przycisku pauzy w trybie debugowania może nie dać rzeczywisty obraz zachowania aplikacji, ponieważ Debugery wprowadzają dodatkowy kod wykonywalny, który może spowolnić niektóre części aplikacji. Można odnieść się do Mike Stall ' s blog post NA możliwe przyczyny spowolnienia aplikacji w środowisku debugowania. Post rzuca światło na pewne powody, takie jak zbyt wiele punktów przerwania, tworzenie obiektów WYJĄTKÓW, nieoptymalizowany kod itp. Ważna jest część o nieoptymalizowanym kodzie - tryb "debug" spowoduje wiele optymalizacji (Zwykle wprowadzanie kodu i ponowne zamawianie) jest wyrzucane z okna, aby umożliwić hostowi debugowania (proces uruchamiający kod) i IDE synchronizację wykonania kodu. Dlatego powtarzanie pauzy w trybie "debug" może być złym pomysłem.

Profilery próbkowania są przydatne tylko wtedy, gdy

1. monitorujesz runtime z niewielką liczbą wątków. Najlepiej jedną.
2. głębokość stosu wywołań każdego wątku jest stosunkowo niewielka (w celu zmniejszenia niesamowitego narzutu w zbieraniu próbki).
3. martwisz się tylko o czas zegara ściennego, a nie o inne liczniki lub wąskie gardła zasobów.
4. nie użyłeś kodu do celów zarządzania i monitorowania (stąd żądania zrzutu stosu)
5. Ty błędnie uważają, że usunięcie ramki stosu jest skuteczną strategią poprawy wydajności, niezależnie od tego, czy koszty nieodłączne (z wyłączeniem callees) są praktycznie zerowe, czy nie
6. nie musisz się martwić, aby nauczyć się codziennego stosowania inżynierii wydajności oprogramowania w swojej pracy
7. ....

Stack trace migawki pozwalają tylko zobaczyć stroboskopowe zdjęcia rentgenowskie aplikacji. Możesz wymagać więcej zgromadzonej wiedzy, którą może Ci dać profiler.

Sztuką jest dobrze znać swoje narzędzia i wybrać najlepsze do pracy pod ręką.

To muszą być trywialne przykłady, z którymi pracujesz, aby uzyskać użyteczne wyniki swojej metody. Nie mogę myśleć o projekcie, w którym profilowanie było użyteczne (jakąkolwiek metodą), które uzyskałoby przyzwoite wyniki dzięki Twojej "szybkiej i skutecznej" metodzie. Czas potrzebny na uruchomienie i zatrzymanie niektórych aplikacji już stawia Twoje twierdzenie o "szybkim" pod znakiem zapytania.

Ponownie, w przypadku nietrywialnych programów metoda, którą popierasz, jest bezużyteczna.

Edytuj: Odnośnie "dlaczego nie jest lepiej znany"?

Z mojego doświadczenia wynika, że recenzje kodu unikają złej jakości kodu i algorytmów, a profilowanie również je znajdzie. Jeśli chcesz kontynuować swoją metodę, która jest świetna - ale myślę, że dla większości społeczności zawodowej jest to tak daleko na liście rzeczy do wypróbowania, że nigdy nie uzyska pozytywnego wzmocnienia jako dobre wykorzystanie czasu.

Wydaje się być dość niedokładne w przypadku małych zestawów próbek i uzyskanie dużych zestawów próbek zajęłoby dużo czasu, co były lepiej spędzone z innymi użytecznymi zajęciami.

Co jeśli program jest w produkcji i jest używany w tym samym czasie przez płacących klientów lub współpracowników. Profiler pozwala na obserwację bez ingerencji (tyle, bo oczywiście będzie też miał mały hit zgodnie z zasadą Heisenberga ).

Profilowanie może również zapewnić znacznie bogatsze i bardziej szczegółowe dokładne raporty. Na dłuższą metę będzie to szybsze.

EDIT 2008/11/25: OK, odpowiedź Vineeta wreszcie dała mi do zrozumienia o co tu chodzi. Lepiej późno niż wcale.

W jakiś sposób pomysł się rozluźnił w kraju, że problemy z wydajnością można znaleźć poprzez pomiar wydajności. To jest mylące środki z końcami. Jakoś uniknąłem tego przez pojedyncze kroki całych programów dawno temu. Nie narzekałem na to, że spowalniałem to do ludzkiej prędkości. Próbowałem sprawdzić, czy robi złe, czy niepotrzebne rzeczy. Czyli jak szybko znaleźć oprogramowanie i usunąć niepotrzebne operacje.

Nikt nie ma cierpliwości do pojedynczych kroków w dzisiejszych czasach, ale następną najlepszą rzeczą jest wybrać liczbę cykli losowo i zapytać, jakie są ich powody. (To jest to, co często można powiedzieć stos połączeń.) Jeśli dobry procent z nich nie ma dobrych powodów, możesz coś z tym zrobić.

W dzisiejszych czasach jest trudniej, co z threadingiem i asynchronią, ale w ten sposóbdostrajam oprogramowanie-znajdując niepotrzebne cykle. Nie widząc jak szybko jest - robię to na końcu.

Oto dlaczego próbkowanie stosu wywołań nie może dać błędnej odpowiedzi i dlaczego nie potrzeba wielu próbek.

W interwale zainteresowania, kiedy program zajmuje więcej czasu niż byś chciał, stos wywołań istnieje w sposób ciągły, nawet jeśli nie próbkujesz go.

• jeśli instrukcja I znajduje się na stosie wywołań dla ułamka P(I) tego czasu, usunięcie jej z programu, jeśli można, zaoszczędziłoby dokładnie tyle. Jeśli to to nie jest oczywiste, zastanów się.

Jeśli instrukcja pokazuje się na M = 2 lub więcej próbek, z N, jej P (I) jest w przybliżeniu M/N i jest zdecydowanie znacząca.

Jedynym sposobem, aby nie zobaczyć instrukcji jest magicznie czas wszystkie próbki dla, gdy instrukcja nie jest na stosie połączeń. Prosty fakt, że jest obecny przez ułamek czasu, jest tym, co naraża go na twoje sondy.

Więc proces strojenia wydajności jest prostą sprawą o odebraniu instrukcji (głównie instrukcji wywołania funkcji), które podnoszą głowy, pojawiając się na wielu próbkach stosu połączeń. To są wysokie drzewa w lesie.

Zauważ, że nie musimy przejmować się wykresem wywołania, jak długo trwa funkcja, ile razy jest wywoływana lub rekurencja.

Jestem przeciw zaciemnianiu, nie przeciw profilerom. Dają dużo statystyk, ale większość nie daje P (I), a większość użytkowników nie zdaje sobie sprawy, że to ważne.

Możesz mówić o lasach i drzewach, ale w przypadku każdego problemu wydajności, który możesz naprawić poprzez modyfikację kodu, musisz zmodyfikować instrukcje, w szczególności instrukcje z wysokim P (I). Więc musisz wiedzieć, gdzie one są, najlepiej bez grania Sherlocka Holmesa. Próbkowanie stosu mówi dokładnie, gdzie są.

Ta technika jest trudniejsza do zastosowania w wielowątkowych, sterowanych zdarzeniami lub systemach w produkcji. Tam profilerzy, gdyby zgłosili P (I), mogliby naprawdę pomóc.

Przechodzenie przez kod jest świetne, aby zobaczyć szczegóły i rozwiązywanie problemów algorytmów. To jak patrzenie na drzewo z bliska i podążanie za każdą żyłą kory i gałęzi indywidualnie.

Profilowanie pozwala zobaczyć duży obraz i szybko zidentyfikować problemy - jak krok do tyłu, patrząc na cały las i zauważając najwyższe drzewa. Sortując wywołania funkcji według długości czasu wykonania, można szybko zidentyfikować obszary, które są problemy.

Używałem tej metody dla Commodore 64 BASIC wiele lat temu. To zaskakujące, jak dobrze to działa.

Zwykle używałem go w programach czasu rzeczywistego, które przekroczyły swój czas. Nie można ręcznie zatrzymać i ponownie uruchomić kodu, który musi działać 60 razy na sekundę.

Użyłem go również do wytropienia wąskiego gardła w kompilatorze, który napisałem. Nie chciałbyś próbować ręcznie łamać takiego programu, ponieważ naprawdę nie masz możliwości sprawdzenia, czy łamiesz w miejscu, w którym znajduje się bottlenck, czy po prostu w miejscu po wąskim gardle, gdy system operacyjny może go zatrzymać. A co jeśli głównym wąskim gardłem jest coś, z czym nie możesz nic zrobić, ale chciałbyś pozbyć się wszystkich innych dużych wąskich gardeł w systemie? Jak ustalić priorytety, które wąskie gardła zaatakować jako pierwsze, gdy nie masz dobrych danych na temat tego, gdzie są wszystkie i jaki jest ich względny wpływ na każde z nich?

Im większy jest Twój program, tym bardziej przydatny będzie profiler. Jeśli potrzebujesz zoptymalizować program zawierający tysiące gałęzi warunkowych, Profiler może być niezastąpiony. Wprowadź największą próbkę danych testowych, a po zakończeniu zaimportuj dane profilowania do programu Excel. Następnie sprawdzasz założenia dotyczące prawdopodobnych hot spotów na podstawie rzeczywistych danych. Zawsze są niespodzianki.