Come profili il tuo codice?
https://stackoverflow.com/questions/56672
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Spero che non tutti utilizzino Rational Purify.
Allora cosa fai quando vuoi misurare:
- tempo impiegato da una funzione
- picco di utilizzo della memoria
- copertura del codice
Al momento, lo facciamo manualmente [usando istruzioni di log con timestamp e un altro script per analizzare il log e l'output in Excel.uff...)
Cosa raccomanderesti?Indicare strumenti o tecniche sarebbe apprezzato!
MODIFICARE:Mi spiace, non ho specificato prima l'ambiente, È semplice C su un cellulare proprietario piattaforma
Soluzione
Probabilmente desideri strumenti diversi per la profilazione delle prestazioni e la copertura del codice.
Per la profilazione preferisco Shark su MacOSX.È gratuito da Apple e molto buono.Se la tua app è Vanilla C dovresti essere in grado di usarla, se riesci a procurarti un Mac.
Per la profilazione su Windows è possibile utilizzare LTProf.Economico, ma non eccezionale:http://successfulsoftware.net/2007/12/18/optimising-your-application/
(Penso che Microsoft si stia davvero dando la zappa sui piedi non fornendo un profiler decente con le versioni più economiche di Visual Studio.)
Per la copertura preferisco Coverage Validator su Windows:http://successfulsoftware.net/2008/03/10/coverage-validator/Aggiorna la copertura in tempo reale.
Altri suggerimenti
L'ho fatto spesso.Se hai un IDE o un ICE, c'è una tecnica ciò richiede un certo sforzo manuale, ma funziona senza problemi.
Avvertimento:i programmatori moderni lo odiano e verrò sottovalutato.Amano i loro strumenti.Ma funziona davvero e non sempre hai gli strumenti utili.
Presumo che nel tuo caso il codice sia qualcosa come DSP o video che funziona con un timer e deve essere veloce.Supponiamo che ciò che esegui ad ogni tick del timer sia la subroutine A.Scrivi del codice di prova per eseguire la subroutine A in un ciclo semplice, diciamo 1000 volte, o abbastanza a lungo da farti aspettare almeno diversi secondi.
Mentre è in esecuzione, interrompilo in modo casuale con un tasto di pausa, campiona lo stack di chiamate (non solo il contatore del programma) e registralo.(Questa è la parte manuale.) Fallo un certo numero di volte, ad esempio 10.Una volta non è sufficiente.
Ora cerca i punti in comune tra i campioni dello stack.Cerca qualsiasi istruzione o istruzione di chiamata che appare su almeno 2 campioni.Ce ne saranno molti, ma alcuni di essi saranno in codice che potresti ottimizzare.
Fallo e otterrai una bella accelerazione, garantito.Le 1000 iterazioni richiederanno meno tempo.
Il motivo per cui non hai bisogno di molti campioni è che non stai cercando piccole cose.Ad esempio, se vedi una particolare istruzione di chiamata su 5 campioni su 10, è responsabile di circa il 50% del tempo di esecuzione totale.Un numero maggiore di campioni ti direbbe con maggiore precisione qual è la percentuale, se davvero lo vuoi sapere.Se sei come me, tutto ciò che vuoi sapere è dove si trova, così puoi aggiustarlo e passare a quello successivo.
Fallo finché non riesci a trovare altro da ottimizzare e sarai alla velocità massima o quasi.
Per le applicazioni complesse sono un grande fan di Intel Vtune.Si tratta di una mentalità leggermente diversa rispetto a quella di un profiler tradizionale che strumentalizza il codice.Funziona campionando il processore per vedere dove si trova il puntatore dell'istruzione 1.000 volte al secondo.Ha l'enorme vantaggio di non richiedere alcuna modifica ai file binari, il che molto spesso cambierebbe i tempi di ciò che stai cercando di misurare.
Sfortunatamente non va bene per .net o Java poiché non esiste un modo per Vtune di mappare il puntatore dell'istruzione sul simbolo come avviene con il codice tradizionale.
Ti consente inoltre di misurare tutti i tipi di altri parametri incentrati sul processore/hardware, come orologi per istruzione, riscontri/mancati della cache, riscontri/mancati TLB, ecc. che ti consentono di identificare il motivo per cui alcune sezioni di codice potrebbero richiedere più tempo per l'esecuzione di quanto faresti aspettarsi semplicemente ispezionando il codice.
Se stai realizzando un sistema "C" incorporato "sul metallo" (non sono sicuro di cosa implicasse "mobile" nel tuo post), di solito hai una sorta di ISR timer, in cui è abbastanza facile campionare l'indirizzo del codice in cui si è verificato l'interrupt (scavando nello stack o esaminando i registri dei collegamenti o altro).Quindi è banale creare un istogramma di indirizzi con una combinazione di granularità/intervallo di interesse.
Di solito non è poi così difficile inventare una combinazione di codice/script/fogli Excel che unisca i conteggi del tuo istogramma con gli indirizzi del tuo file di simboli/elenco del linker per fornirti informazioni sul profilo.
Se hai molta RAM limitata, può essere un po' complicato raccogliere dati sufficienti affinché l'operazione sia semplice e utile, ma dovresti dirci qualcosa in più sulla tua piattaforma.
nProf - Gratuito, lo fa per .NET.
Porta a termine il lavoro, almeno quanto basta per vedere l'80/20.(20% del codice, impiegando l'80% del tempo)
IL Perftools di Google sono estremamente utili a questo riguardo.
Io uso devpartner con MSVC 6 e XP
Come funzioneranno gli strumenti se la tua piattaforma è un sistema operativo proprietario?Penso che tu stia facendo del tuo meglio in questo momento
