La mia comprensione è che per impostazione predefinita gprof tiene conto del tempo della CPU. C'è un modo per portarlo al profilo in base all'orario dell'orologio a muro?Ottieni gprof sul profilo in base all'orario dell'orologio a muro?
Il mio programma esegue molto i/o del disco, quindi il tempo di CPU utilizzato rappresenta solo una frazione del tempo di esecuzione effettivo. Ho bisogno di sapere quali parti del disco i/o occupano più tempo.
gprof non lo farà. Look at this.
In poche parole: Sotto gdb, farlo funzionare e fare Ctrl-Break o Ctrl-C per 10 volte a caso, e visualizzare lo stack di chiamate. Se il tuo I/O sta prendendo (per esempio) il 60% delle volte, poi su (approssimativamente) 6 pause su 10, lo vedrai nella routine writebuf o readbuf, e le linee di codice che richiedono che I/O essere chiaramente visualizzato in pila.
È inoltre possibile utilizzare lsstack per ottenere le stesse informazioni.
Hmm ... questo metodo non sarebbe statisticamente inaccurato? Esiste un modo automatico per fare ciò, che richiede molto più di 10 campioni, ad esempio 1000 campioni, ma a intervalli uniformi, quindi segnala quali funzioni sono state incontrate più spesso? – jetwolf
@jetwolf: Zoom è un esempio di un profiler che lo fa con 10^3 campioni, ma controlla il primo link, in particolare gli articoli 5, 2, 7 e 9. –
@jetwolf: Esempio: supponiamo che I/O sia esattamente 60 %. Deviazione standard del numero di campioni per mostrare che è sqrt (NF (1-F)). Per 10 campioni che è +/- 1,55, per 1000, è 15,5. Quindi in 10 campioni lo vedrete all'incirca 4,45 - 7,55 volte. In 1000 campioni lo vedrai approssimativamente 584,5 - 615,5 volte. Ad ogni modo, vedrai esattamente cosa sta causando, quindi se è risolvibile, puoi correggerlo. –
È possibile utilizzare strace o cachegrind per profilare correttamente il codice. strace ti fornirà i dettagli del tempo trascorso nelle chiamate di sistema e cachegrind fornirà un'analisi dettagliata dell'utilizzo delle risorse.
È molto semplice cambiare gprof per eseguire il profiling dell'orologio a muro. Gli unici 8 caratteri per sostituire sono:
ITIMER_PROF -> ITIMER_REAL
SIGPROF -> SIGALRM
nel file glibc/sysdeps/posix/profil.c, funzionano __profil, nei pressi delle chiamate a setitimer e sigaction (più precisamente __Setitimer e __sigaction)
Dopo il cambio qualsiasi programma che utilizza SIGALRM sarà essere rotto e qualsiasi programma che non ha codice di riavvio syscall di blocco può dare risultati errati.
Inoltre, è possibile modificare direttamente i valori int in binario glibc (per favore, non lo fate questo su tutto il sistema libc.so, fare una copia separata e dare al programma con LD_LIBRARY_PATH)
Per cerotto binario, ITIMER_PROF è 2 ; ITIMER_REAL è 0; SIGPROF è 27 (0x1b); SIGALRM è 14 (0x0e). Ci sono due posizioni per ogni costante nella funzione profil di glibc.
Un altro modo è scrivere un debugger ptrace, che cambierà gli argomenti delle funzioni setitimer e sigaction in fase di esecuzione.
Sfortunatamente, dopo aver modificato un binario libc, questo approccio fallì. Il timer e il segnale sono cambiati, ma ... Il 'profil()' (che è usato da gmon, attivato da '-pg') non può profilare le librerie dinamiche (dove risiedono la maggior parte delle funzioni di blocco). Inoltre, 'eip', visto dal gestore di segnale quando il blocco di syscall è attivo, è sbagliato per le librerie dinamiche (punta a glibc, ma non nel wrapper syscall) ed è NULL per il collegamento statico. – osgx
È possibile misurare l'ora dell'orologio da parete utilizzando profiler da google-perftools. Per cambiare google profiler in modalità wall-clock, imposta la variabile di ambiente CPUPROFILE_REALTIME = 1.
404 su quel collegamento. Potresti aggiornarlo? –
Probabilmente vuoi qualcosa di diverso da gprof per questo. – WhirlWind
Come cosa ad esempio? – jetwolf
dai un'occhiata a dtrace, a seconda della tua architettura. – WhirlWind