Czy klasy filtrowania dla profilowania cpu działają w języku Java VisualVM?

Question

Chcę filtrować, które klasy są profilowane przez cpu w Javie VisualVm (wersja 1.7.0 b110325). W tym celu próbowałem pod Profiler -> Ustawienia -> CPU-Settings, aby ustawić "Tylko profil klasy" do mojego testowanego pakietu, który nie przyniósł żadnego efektu. Następnie próbowałem pozbyć się wszystkich klas java. * I sun. *, Ustawiając je w "Nie profiluj klas", co również nie miało żadnego efektu.

Czy to po prostu błąd? Czy może czegoś brakuje? Czy jest w pobliżu praca? Mam na myśli inne niż:

• płatniczą dla lepszego profilera
• robi próbkowanie ręcznie (patrz One could use a profiler, but why not just halt the program?)
• przełącznik widoku połączeń drzewo, które nie jest dobre, ponieważ tylko w widoku Profiler daje mi procenty zużytego procesora na metodę.

Chcę to zrobić głównie w celu uzyskania połowy poprawnych procentów zużytego procesora na metodę. W tym celu muszę pozbyć się irytujących pomiarów, np. dla sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run() (około 70%). Wielu użytkowników ma ten problem, patrz np.

• Java VisualVM giving bizarre results for CPU profiling - Has anyone else run into this?
• rmi.transport.tcp.tcptransport Connectionhandler consumes much CPU
• Can't see my own application methods in Java VisualVM.

Answer 1

W profilu widzisz sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(), ponieważ została wybrana opcja Profil nowy Runnables. Ponadto, jeśli zrobiłeś migawkę sesji profilowania, możesz zobaczyć cały moduł wywoławczy dla dowolnej metody hotspot - w ten sposób możesz przejść od metody run() do własnych metod logiki aplikacji, odfiltrowując szumy wygenerowany przez opcję Nowy profil Runnables.

Answer 2

OK, ponieważ Twoim celem jest, aby kod działał tak szybko, jak to możliwe, pozwól mi zasugerować, jak to zrobić. Nie jestem ekspertem od VisualVM, ale mogę powiedzieć, co działa. (Tylko kilku programistów faktycznie mówi ci, co musisz wiedzieć, to jest - które linie twojego kodu są na stosie zdrowym ułamkiem czasu zegara ściennego.)

Jedyny pomiar, z jakim kiedykolwiek sobie poradzę, to stoper na czas ogólny lub, alternatywnie, jeśli kod ma wartość podobną do liczby klatek na sekundę, liczba klatek na sekundę. Nie potrzebuję żadnego dalszego podziału precyzji, ponieważ jest to w najlepszym razie odległa wskazówka co do marnowania czasu (i częściej zupełnie nieistotnego), kiedy istnieje bardzo bezpośredni sposób na zlokalizowanie go.

Jeśli nie chcesz wykonywać random-pausing, to zależy od Ciebie, ale udowodniono, że działa, i here's an example of a 43x speedup.

Zasadniczo chodzi o to, że otrzymujesz (małą, jak 10) liczbę próbek stosu, wykonanych losowo w czasie zegarowym. Każda próbka składa się (oczywiście) z listy stron z telefonami i prawdopodobnie strony bez połączenia na końcu. (Jeśli próbka jest w trakcie operacji we/wy lub uśpienia, zakończy się ona wywołaniem systemowym, co jest w porządku.To właśnie chcesz wiedzieć.)

Jeśli istnieje sposób na przyspieszenie kodu (i prawie na pewno jest), zobaczysz go jako linię kodu, która pojawia się na co najmniej jednej z próbek stosu. Prawdopodobieństwo, że pojawi się na jednej próbce jest dokładnie takie samo, jak ułamek czasu, którego używa. Więc jeśli istnieje strona połączenia lub inna linia kodu korzystająca z zdrowej części czasu, a unikniesz jej wykonania, całkowity czas zmniejszy się o tę część.

Nie znam wszystkich profilerów, ale ten, który znam, może ci powiedzieć, że jest to Zoom. Inni mogą to zrobić. Mogą być bardziej oszałamiające, ale nie działają szybciej ani lepiej niż metoda ręczna, gdy celem jest maksymalizacja wydajności.