2010-07-19 16 views
5

Ho un'applicazione che gira su un processore embedded (ARM) e vorrei profilare l'applicazione per avere un'idea di dove sta usando le risorse di sistema, come CPU, memoria, IO, ecc. l'applicazione è in esecuzione su Linux, quindi presumo ci sia un numero di applicazioni di profilazione disponibili. Qualcuno ha qualche suggerimento?Applicazione di profiling incorporata

Grazie!

modifica: dovrei aggiungere anche la versione di Linux che stiamo usando è un po 'vecchia (2.6.18). Sfortunatamente non ho molto controllo su questo adesso.

risposta

2

Come dice Bobah, gprof e valgrind sono utili. Si potrebbe anche voler provare OProfile. Se la tua applicazione è in C++ (come indicato dai tag), potresti prendere in considerazione la possibilità di disabilitare le eccezioni (se il compilatore ti consente) ed evitare le conversioni dinamiche, come menzionato sopra da sashang. Vedi anche Embedded C++.

+0

Grazie, OProfile era il biglietto. È molto bello per il profiling incorporato. – kidjan

2

se il vostro Linux non è molto limitato, si potrebbe essere gprof e valgrind utile

+0

Per utilizzarli, dovrei portarli sull'ARM, non è vero? – kidjan

+3

Valgrind è, secondo la mia esperienza, inutilizzabile nei dispositivi embedded, è troppo lento. invece, grpof funziona alla grande. gprof è uno strumento fornito da GCC stesso, quindi se hai GCC funzionante, hai gprof. Produrrà un file di statistiche che potrai poi analizzare in un PC con elementi GUI completi. – Gianni

0

In una nota correlata, il gruppo di lavoro C++ ha fatto una relazione tecnica sul costo delle prestazioni di varie caratteristiche del linguaggio C++. Ad esempio, analizzano il costo di dynamic_casting a uno o due livelli in profondità. I report qui http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf e potrebbero darti qualche informazione su dove potrebbero essere i punti di dolore nell'applicazione incorporata.

0

gprof may disappoint you.

Assumendo il programma che si sta eseguendo il test è abbastanza grande per essere utile, allora è probabile che l'albero chiamata potrebbe essere potata, in modo che le migliori opportunità di ottimizzazione sono metodo della funzione/le chiamate che è possibile rimuovere o evitare. Quel collegamento mostra un buon modo per trovarli.

Molte persone si avvicinano a questo come una specie di processo di misurazione gerarchico dei tempi di misurazione. Oppure puoi semplicemente prenderlo in flagrante, che è quello che faccio.

+0

Sì, interrompere un programma in esecuzione su un processore incorporato .... non è facile. Pertanto, mentre il metodo descritto potrebbe funzionare correttamente per un desktop con un debugger completo in allegato, è problematico per lo sviluppo integrato. E OProfile fondamentalmente sta facendo esattamente lo stesso metodo che stai proponendo, tranne in un modo molto più coerente e utile. – kidjan

+0

@kidjan: Non ho familiarità con OProfile. Prende campioni di stack? A tempo di orologio da parete (vale a dire anche se bloccato)? Riassume le percentuali al livello della linea di codice, non solo le funzioni? Ignora la ricorsione? Quindi sta arrivando. (Questo è ciò che fanno Zoom e LTProf.) Ho dovuto usare un box ICE su un processore embedded per fare questo. Ti garantisco che potrebbe non essere facile, ma penso che niente ti trovi come in realtà studiando singoli campioni dello stack. –

+0

Fa tutte quelle cose. E mettere in pausa un processore incorporato, in un programma in tempo reale (stiamo facendo streaming video in diretta, tra le altre cose sensibili in tempo reale, quindi "Heisenberg" vale) non è solo "non facile", è "non possibile". Strumenti come OProfile sono l'unica opzione. – kidjan