2010-05-24 13 views
5

Qualcuno conosce il profiler del codice C come gprof che offre tempi di chiamata della funzione in microsecondi anziché millisecondi?profiler al microsecondo per il codice C

+0

E ho bisogno di lavorare su Ubuntu e di essere un freeware. – godot101

+0

Stai chiedendo perché vuoi scoprire cosa puoi cambiare per farcelo meno tempo? –

+0

@Mike: Voglio scoprire quanto tempo impiega il mio codice C per eseguire, e la precisione millisecondo che gprof fornisce fin d'ora non è abbastanza buona come il mio intero codice viene eseguito in pochi ms. Quindi, ho bisogno di una precisione migliore per il tempo impiegato in ogni chiamata di funzione. – godot101

risposta

3

Dai uno sguardo allo Linux perf. Avrai comunque bisogno di un kernel abbastanza recente.

3

Lasciatemi solo suggerire come gestirlo, supponendo che abbiate il codice sorgente.

Sapendo quanto tempo una funzione prende inclusivo per invocazione (compresi l'I/O), in media, moltiplicato per il numero di invocazioni, diviso per il tempo totale di esecuzione, darebbe la frazione di tempo sotto il controllo di quella funzione. Quella frazione è il modo in cui sai se la funzione è un tempo sufficiente per preoccuparti di ottimizzare. Non è facile ottenere informazioni da gprof.

Un altro modo per apprendere quale frazione del tempo inclusivo viene speso sotto il controllo di ciascuna funzione è il campionamento a tempo o casuale dello stack di chiamate. Se una funzione appare su una frazione X dei campioni (anche se appare più di una volta in un campione), allora X è la frazione di tempo che impiega (entro un margine di errore). Inoltre, questo ti dà per riga frazione di tempo, non solo per funzione.

Quella frazione X è l'informazione più preziosa che si possa ottenere, perché è il tempo totale che si può potenzialmente risparmiare ottimizzando quella funzione o linea di codice.

Il Zoom profiler è uno strumento utile per ottenere queste informazioni.

Quello che vorrei fare è avvolgere un ciclo di esecuzione prolungata attorno al codice di livello superiore, in modo che venga eseguito ripetutamente, abbastanza a lungo da richiedere almeno alcuni secondi. Quindi campionerei manualmente lo stack interrompendolo o interrompendolo a caso. In realtà occorrono pochissimi campioni, come 10 o 20, per ottenere un'immagine veramente chiara delle funzioni e/o linee di codice che richiedono più tempo.

Here's an example.

P.S. Se sei preoccupato per l'accuratezza statistica, lasciami ottenere quantitativo. Se una funzione o una riga di codice è in pila esattamente il 50% delle volte e si prendono 10 campioni, il numero di campioni che lo mostrano sarà 5 +/- 1,6, con un margine di errore del 16%. Se il tempo effettivo è più piccolo o più grande, il margine di errore si riduce. Puoi anche ridurre il margine di errore prendendo più campioni. Per ottenere l'1,6%, prendi 1000 campioni. In realtà, una volta trovato il problema, sta a te decidere se hai bisogno di un margine di errore più piccolo.

1

oprofile consente di ottenere tempi di risoluzione del clock, vale a dire nanosecondi, produce file di output compatibili con gprof, quindi molto comodo da usare.

http://oprofile.sourceforge.net/news/

2

gprof dà risultati sia in millisecondi o in microsecondi. Non conosco la logica esatta, ma la mia esperienza è che mostrerà risultati in microsecondi quando pensa che ci sia abbastanza precisione per questo. Per ottenere un output in microsecondi, è necessario eseguire il programma per un tempo più lungo e/o non avere alcuna routine che richiede troppo tempo per essere eseguita.