Profilatori Open Source consigliati

Question

Sto cercando di trovare profiler open source piuttosto che utilizzare uno dei profiler commerciali che devo pagare $ $ per. Quando ho eseguito una ricerca su SourceForge, mi sono imbattuto in questi quattro profiler C++ che ho pensato che fosse abbastanza promettente:

1. Shiny: C++ Profiler
2. Low Fat Profiler
3. Luca Stackwalker
4. FreeProfiler

Non sono sicuro quale tra i profiler sia il migliore da utilizzare in termini di apprendimento delle prestazioni del mio programma. Sarebbe bello sentire alcuni suggerimenti.

Answer 1

Si potrebbe provare Windows Performance Toolkit. Completamente gratuito da usare. Questo blog entry ha un esempio di come eseguire il profiling basato su esempi.

Answer 2

Utilizziamo LtProf e ne siamo rimasti soddisfatti. Non è open source, ma solo $$, non $$$ :-)

Answer 3

• Valgrind (e relativi strumenti come cachegrind, ecc)
• Google performance tools

Answer 4

C'è più di un modo per fare esso.

Don't forget the no-profiler method.

maggior parte profilatrici assumono Occorrono 1) elevata precisione statistica di temporizzazione (lotti di campioni), e 2) scarsa precisione di identificazione del problema (funzioni & call-grafici).

Queste priorità possono essere invertite. Cioè il problema può essere localizzato all'indirizzo della macchina preciso, mentre la precisione dei costi è una funzione del numero di campioni.

La maggior parte dei problemi reali costa almeno il 10%, in cui l'alta precisione non è essenziale.

Esempio: se qualcosa sta facendo sì che il programma impieghi 2 volte il tempo necessario, significa che c'è del codice al suo interno che costa il 50%. Se si prendono 10 campioni dello stack di chiamata mentre è lento, le linee precise del codice saranno presenti su circa 5 di esse. Più grande è il programma, più è probabile che il problema sia una chiamata da qualche parte in mid-stack.

È anti-intuitivo, lo so.

NOTA: xPerf è quasi arrivato, ma non del tutto (per quanto ne so). Prende campioni dello stack delle chiamate e li salva - questo è buono. Ecco quello che penso che sia necessario:

• Dovrebbe solo prendere campioni quando li vuoi. Così com'è, devi filtrare quelli irrilevanti.

• Nella visualizzazione stack deve mostrare linee o indirizzi specifici a cui le chiamate avvengono, non solo intere funzioni. (Forse può farlo, non potrei dire dal blog.)

• Se si fa clic per ottenere la vista farfalla, incentrata su una singola istruzione di chiamata, o istruzione foglia, dovrebbe mostrare non la frazione CPU, ma la frazione di campioni dello stack contenenti tale istruzione. Sarebbe una misura diretta del costo di quella istruzione, in una frazione di tempo. (Forse può farlo, non saprei dirlo.) Quindi, ad esempio, anche se un'istruzione fosse una chiamata al file-aperto o qualcos'altro che inattiva il thread, costa comunque l'ora dell'orologio a muro, e devi sapere che.

NOTA: Ho appena dato un'occhiata Luca Stackwalker, e applicare le stesse osservazioni. Penso che sia sulla strada giusta ma ha bisogno del lavoro dell'interfaccia utente.

aggiunto: Dopo aver preso visione LukeStackwalker più attentamente, ho paura che cade vittima l'ipotesi che le funzioni di misurazione è più importante di localizzare dichiarazioni. Quindi, su ogni campione dello stack di chiamate, aggiorna le informazioni sul tempo a livello di funzione, ma tutto ciò che fa con le informazioni sul numero di linea è tenere traccia dei numeri di linea min e max in ogni funzione, che, più campioni prende, il più lontani quelli ottengono. Quindi in pratica getta via le informazioni più importanti - le informazioni sul numero di riga. Il motivo per cui è importante è che se si decide di ottimizzare una funzione, è necessario sapere quali linee in esso devono funzionare e quelle linee erano nello stack (prima che venissero scartate).

Si potrebbe obiettare che se le informazioni numero di riga sono stati mantenuto sarebbe a corto di stoccaggio in fretta. Due risposte 1) Ci sono solo tante righe che appaiono sui campioni, e vengono visualizzate ripetutamente. 2) Non sono necessari molti campioni - l'ipotesi che sia necessaria un'elevata precisione statistica di misurazione è sempre stata assunta, ma mai giustificata.

ho il sospetto che altri campionatori pila, come xperf, hanno problemi simili.

Answer 5

Non è open source, ma AMD CodeAnalyst è gratuito. Funziona anche su CPU Intel nonostante il nome. Esistono versioni disponibili per Windows (con integrazione di Visual Studio) e Linux.

Answer 6

Da quelli che hanno elencato, ho trovato Luke Stackwalker a funzionare al meglio - Mi piaceva la sua GUI, era facile da ottenere in esecuzione.

Altro simile è Very Sleepy - funzionalità simile, il campionamento sembra più affidabile, la GUI è forse un po 'più difficile da usare (non quella grafica).

---

Dopo aver trascorso un po 'di tempo con loro, ho trovato uno svantaggio piuttosto importante. Mentre entrambi cercano di campionare a una risoluzione di 1 ms, in pratica non lo raggiungono perché il loro metodo di campionamento (StackWalk64 del processo allegato) è troppo lento. Per la mia applicazione ci vogliono qualcosa come 5-20 ms per ottenere un callstack. Questo non solo rende imprecisi i risultati, ma li rende anche distorti, poiché i callstack brevi vengono fatti avanzare più velocemente, quindi tendono a ottenere più hit.