Co to jest „(program)” w narzędziu do profilowania debugera Chrome?

178

Co to jest „(program)” w kolumnie funkcji debugera Chrome?

javascript google-chrome-devtools

— hvgotcodes
źródło

Odpowiedzi:

(program)to sam Chrome, rdzeń drzewa wywołujący cały inny kod ... jest tam, ponieważ przejście z kodu natywnego na JavaScript, ładowanie zasobów itp. musi się gdzieś rozpocząć :)

Przykłady widoku drzewa można znaleźć w dokumentacji narzędzia dla programistów Chrome .

— Nick Craver
źródło

ah - więc jeśli to wysoki procent, czy mogę coś z tym zrobić?

— hvgotcodes

@hvgotcodes - Brzmi procentowo dla wszystkich poniższych części. Teraz, jeśli samo odsetek ten jest wysoki, nie ma wiele można zrobić .... chyba, że znaczniki w ogóle jest bardzo ciężki.

— Nick Craver

Czy wiesz, jak uzyskać dostęp do kodu w sekcji „(program)”? W jakiś sposób fragmenty JavaScript w projekcie, nad którym obecnie pracuję, tam się kończą, a jedynym sposobem na dostanie się tam w debuggerze jest umieszczenie „debuggera”; w kodzie, co nie jest całkiem wygodne.

— Jaroslav Záruba

Wydaje mi się, że tak naprawdę jest źle i odpowiedź @ user1009908 jest poprawna. To nie jest root, jego natywny kod. Obsługuje to fakt, że przykład widoku drzewa nie pokazuje go jako katalogu głównego.

— studgeek

Jeśli chodzi o wysoki% programu (), czasami animacje css prowadzą do dużego użycia procesora, co zostanie odzwierciedlone w programie (). Niestety profiler nie może pomóc w ustaleniu źródła.

— ǝlǝ

Wierzę, że (program) jest rodzimym kodem, a nie rdzeniem drzewa.

Zobacz ten wątek:

https://bugs.webkit.org/show_bug.cgi?id=88446

Bardziej przypomina to wywołania systemowe niż main ().

Najwyraźniej obejmuje to czas bezczynności. Ponadto niektóre profilowanie (programu) jest dostępne z chrome: // profiler /

— użytkownik1009908
źródło

Zgoda - ale tylko aktualizacja: nie obejmuje już czasu bezczynności. To jest teraz zgłaszane osobno jako (bezczynne)

— Gio

Jak mówi @Nick, musi gdzieś zacząć.

Wygląda na to, że część CPU Profiler jest podobna do wielu innych profilerów opartych na tych samych pojęciach co gprof .

Na przykład self jest prawie bezużyteczną liczbą, chyba że istnieje coś takiego jak bąbelkowa duża tablica liczb w jakimś kodzie, który można edytować. Wysoce nieprawdopodobne.

Suma powinna obejmować osoby biorące udział, więc jest to bardziej przydatne. Jednak dopóki próbki nie zostaną pobrane zarówno w czasie zablokowanym, jak i w czasie wykonywania, nadal jest całkiem bezużyteczne, z wyjątkiem programów całkowicie związanych z procesorem.

Daje ci te statystyki według funkcji, a nie linii kodu. Oznacza to (jeśli możesz polegać na całkowitym procencie), że funkcja kosztuje tyle, w tym sensie, że jeśli możesz w jakiś sposób sprawić, że zajmie to zero czasu, na przykład poprzez zubożenie go, ten procent to tyle, ile możesz zaoszczędzić.

Jeśli więc chcesz skupić się na kosztownej funkcji, musisz znaleźć w niej coś, co można zoptymalizować. Aby to zrobić, musisz wiedzieć, jak czas jest podzielony między wiersze kodu w funkcji. Gdybyś kosztował według linii kodu, zabrałbyś Cię bezpośrednio do tych linii.

Nie wiem, czy będziesz w stanie uzyskać lepszy profiler, taki jak sampler stosu zegara ściennego raportujący na poziomie linii, taki jak Zoom . Oto jak to robię .

— Mike Dunlavey
źródło

@hvgotcodes: Nie jestem pewien. Nie używam ich, ponieważ po prostu robię zrzuty ekranu w debuggerze. Ale jesteś na Linuksie, prawda? Czy możesz dostać próbną kopię Zoom? To całkiem nieźle.

— Mike Dunlavey

@hvgotcodes: Cóż, jedyną pomocą, jaką mogę zaoferować, jest metoda, na której polegam.

— Mike Dunlavey,