Che cos'è "(programma)" nel profiler del debugger di Chrome?

178

Che cos'è "(programma)" nella colonna delle funzioni del debugger di Chrome?

javascript google-chrome-devtools

— hvgotcodes
fonte

Risposte:

(program)è Chrome stesso, la radice dell'albero che chiama tutti gli altri codici ... è lì perché il salto dal codice nativo a JavaScript, il caricamento delle risorse, ecc. deve iniziare da qualche parte :)

Puoi vedere esempi di treeview nei documenti dello strumento di sviluppo di Chrome .

— Nick Craver
fonte

ah - quindi se questa è un'alta percentuale, c'è qualcosa che posso fare al riguardo?

— hvgotcodes,

@hvgotcodes - Sembra la percentuale di tutte le porzioni di seguito. Ora se l' auto- percentuale è alta, non c'è molto che puoi fare .... a meno che il tuo markup in generale non sia molto pesante.

— Nick Craver

Sai, per favore, come accedere al codice nella sezione "(programma)"? In qualche modo parti di JavaScript nel progetto su cui sto attualmente lavorando finiscono lì, e l'unico modo in cui posso arrivarci nel debugger è posizionando "debugger;" nel codice, che non è abbastanza comodo.

— Jaroslav Záruba,

Penso che questo sia effettivamente sbagliato e la risposta di @ user1009908 sia corretta. Non è la radice, il suo codice nativo. È supportato dal fatto che l'esempio della vista ad albero non lo mostra come root.

— Studgeek

Per quanto riguarda l'elevata percentuale di program (), a volte le animazioni CSS comportano un elevato utilizzo della CPU, che si rifletterà nel programma (). Sfortunatamente il profiler non può aiutare a individuare la fonte.

— ılǝ

Credo che (programma) sia un codice nativo, non la radice dell'albero.

Vedi questa discussione:

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

Quindi, più come le chiamate di sistema che come main ().

Apparentemente include i tempi di inattività. Inoltre, alcuni profili di (programma) sono disponibili da chrome: // profiler /

— user1009908
fonte

D'accordo, ma solo un aggiornamento: non include più i tempi di inattività. Ora viene segnalato separatamente come (inattivo)

— Gio

Come dice @ Nick, deve iniziare da qualche parte.

Sembra che la parte di CPU Profiler sia come tanti altri profilatori che si basano sugli stessi concetti di gprof .

Ad esempio, self è quasi un numero inutile a meno che non ci sia qualcosa come una sorta di bolla di una grande matrice di numeri in un codice che è possibile modificare. Altamente improbabile.

Il totale dovrebbe includere i calle, quindi è più utile. Tuttavia, a meno che non vengano prelevati campioni durante il tempo bloccato e durante il tempo di esecuzione, è ancora abbastanza inutile, tranne per i programmi totalmente collegati alla CPU.

Ti dà queste statistiche per funzione, piuttosto che per riga di codice. Ciò significa (se potessi fare affidamento sulla percentuale totale ) che una funzione costa così tanto, nel senso che se in qualche modo riuscissi a farla impiegare zero tempo, come ad esempio eliminandola, quella percentuale è quanto tempo vorresti risparmiare.

Quindi, se vuoi concentrarti su una funzione costosa, devi cercare al suo interno ciò che potrebbe essere ottimizzato. Per fare ciò, devi sapere come il tempo è suddiviso tra le righe di codice nella funzione. Se avessi un costo basato su una riga di codice, ti porterebbe direttamente a quelle righe.

Non so se sarai in grado di ottenere un profiler migliore, come un campionatore dello stack da parete che riporta a livello di linea, come Zoom . Ecco come lo faccio .

— Mike Dunlavey
fonte

@hvgotcodes: non sono sicuro. Non li uso, perché prendo solo gli stackshots in un debugger. Ma sei su Linux, giusto? Puoi ottenere una copia di prova di Zoom? È abbastanza buono.

— Mike Dunlavey,

@hvgotcodes: Bene, l'unico aiuto che posso offrire è il metodo su cui faccio affidamento.

— Mike Dunlavey,