Tutti dicono sempre di definire il profilo del programma prima di eseguire le ottimizzazioni, ma nessuno descrive mai come farlo.Raccomandazioni per i profilatori C?
Quali sono le tue pratiche per il profiling del codice C?
Utilizzando gcc, compilo e legame con -pg (come spiegato per esempio here), poi proseguire eseguendo il programma (secondo i principi proposti anche in quel URL) e l'utilizzo di gprof. Gli strumenti varieranno se si utilizzano diversi compilatori & c, ma l'URL è comunque raccomandato, anche in quel caso, per le parti che riguardano idee generali su come e perché definire il proprio codice.
L'importante è eseguire la tua applicazione sotto il profiler in modo sia rappresentativo del modo in cui l'app viene normalmente utilizzata, sia ripetibile. Una serie specifica di casi di test aiuta. – caf
Visual Studio Team System viene fornito con un buon profiler. Inoltre, Intel VTune non è male.
Se si utilizza Linux, si consiglia la combinazione di ValGrind e CallGrind and KCacheGrind. ValGrind è un metodo eccellente per trovare perdite di memoria e l'estensione CallGrind rende un buon profiler.
NOTA: Ho appena learned che valgrind ora funziona anche su Mac OSX. Tuttavia, CallGrind e KCacheGrind non sono stati aggiornati dal 2005. Potresti voler dare un'occhiata a other front-ends.
Shark/Strumenti (utilizzando dtrace) sono i profiler disponibili su un Mac. Sono piuttosto buoni.
Mi piace particolarmente Shark. Molto utile (e gratuito!). – justin
contento che hai chiesto :-) Se non ti dispiace contrarian, controllare queste risposte:
Let io ci provo dirla in poche parole:
Il programma di aspettare per voi, o ti aspettare per questo? Se non ti fa aspettare, allora non hai problemi, quindi lascia stare.
Se ti fa aspettare, quindi procedere.
vi consiglio di campionamento, che è ottenere i raggi X stroboscopici di ciò che sta facendo il programma quando si è occupato (non in attesa per voi). Ottieni campioni almeno dello stack di chiamate, non solo il contatore del programma. Se si ottengono solo campioni del contatore del programma, non ha senso se il programma impiega un tempo significativo in I/O o nelle routine di libreria, quindi non accontentarsi di ciò.
Se si desidera ottenere molti campioni, è necessario un profiler. Se ne hai solo bisogno, il pulsante di pausa nel debugger funziona perfettamente. Nella mia esperienza, 20 è più che sufficiente, e 5 è spesso sufficiente.
Perché? Supponiamo di avere 1000 campioni dello stack di chiamate.Ogni campione rappresenta un frammento di tempo di orologio da parete che viene speso solo perché ogni singola riga di codice nello stack lo richiedeva. Quindi, se c'è una riga di codice che appare su 557 campioni su 1000, si può supporre che sia responsabile per 557/1000 del tempo, dare o prendere alcuni campioni (15). Ciò significa che se l'intero tempo di esecuzione ti costa $ 100, quella linea di per sé costa $ 55,70, da dare o prendere $ 1,50 **, quindi dovresti cercare di vedere se ne hai davvero bisogno.
Ma hai bisogno di 1000 campioni? Se quella linea costa circa il 55,7% delle volte, se prendi solo 10 campioni, lo vedresti su 6, da o prendi 1,5 campioni. Quindi se vedi una dichiarazione su 6 campioni su 10, sai che ti costa approssimativamente tra $ 45 e $ 75 su quel $ 100. Anche se costa solo $ 45, non vorresti vedere se ne hai davvero bisogno?
Ecco perché non sono necessari molti campioni: non è necessaria molta precisione. Quello che ti serve è quello che ti danno i campioni di pila: ti indicano esattamente le linee più preziose da ottimizzare.
** La deviazione standard del numero di campioni è sqrt(f * (1-f) * nsamp) dove f è la frazione di campioni che contengono la linea.
Grazie mille per questo post molto perspicace! C'è un modo per far sì che lldb faccia il tipo di pausa casuale richiesta? –
@ Koz: non conosco Ildb. Io uso solo qualsiasi debugger in grado di Ctrl-Break. –
Per motivi di completamento, aggiungerei oprofile. È particolarmente interessante se si desidera eseguire il benchmark del kernel.
Che compilatore e sistema operativo stai utilizzando? – LnxPrgr3