2010-09-14 8 views
5

I profiler con cui ho esperienza (principalmente il Digital D D per il profiler di Google che viene fornito con il compilatore) sembrano rallentare in modo massiccio l'esecuzione del programma che viene profilato. Ciò ha un effetto importante sulla mia volontà di usare un profiler, in quanto rende profiling una "vera" esecuzione di molti dei miei programmi, invece di testare su un input molto piccolo, poco pratico. Non so molto su come vengono implementati i profiler. Un rallentamento maggiore (> 2x) quando si profila un dato di fatto, o ci sono profiler che lo evitano? Se può essere evitato, ci sono alcuni profiler veloci disponibili per D, preferibilmente per D2 e ​​preferibilmente gratis?Tutti i profiler hanno rallentato significativamente l'esecuzione?

risposta

15

Non so di profilatori D, ma in generale ci sono due modi diversi in cui un profiler può raccogliere informazioni di profilazione.

Il primo è tramite strumentazione, mediante l'iniezione di chiamate di registrazione in tutto il luogo. Questo rallenta l'applicazione più o meno. In genere più.

Il secondo è il campionamento. Quindi il profiler interrompe l'applicazione a intervalli regolari e ispeziona lo stack di chiamate. Ciò non rallenta affatto l'applicazione.

Lo svantaggio di un profiler di campionamento è che il risultato non è dettagliato come con un profiler di strumentazione.

Controllare la documentazione del proprio profiler se è possibile eseguire con campionamento invece di strumentazione. Altrimenti hai alcuni nuovi termini di Google in "campionamento" e "strumentazione".

+0

++ Sì, regole di campionamento! Ma non solo qualche vecchio campionamento. Campionamento dello stack di chiamate, sull'ora dell'orologio a muro e segnalazione per riga (non funzione) della percentuale di campioni che contengono quella linea. E il dettaglio in più che ottieni con la strumentazione è comunque solo rumore, se il tuo obiettivo è trovare il codice che ha bisogno di essere ottimizzato. –

+0

Per questo motivo tendo a preferire fortemente i profilatori di campionamento laddove possibile - tendono a fornire molti dati affidabili per un costo relativamente ridotto in termini di prestazioni e posso eseguirlo per un lungo periodo per ottenere la media dei risultati da un processo stocastico e rumoroso (come una funzione che impiega 1ms il 90% delle volte in cui viene chiamata e 500ms l'altro 10%). – Crashworks

+0

Trovo l'esatto conteggio di chiamata funzione che gli profiler di strumentazione danno di volta in volta utile. Se carico 120 clienti in una lista, osservo le funzioni chiamate 120 (e peggio n x 120) volte. Posso quindi trovare le funzioni chiamate per errore (cioè attivate da un evento). O le chiamate fatte per ogni articolo in cui una chiamata per tutte loro dovrebbe essere sufficiente. –

1

Direi di sì, sia le forme di campionamento che di strumentazione di profilazione tassheranno pesantemente il tuo programma, indipendentemente dal profiler che stai utilizzando e dalla lingua.

+1

molti profilatori di campionamento possono ridimensionare la frequenza con cui prelevano i campioni. Ciò consente che il sovraccarico sia considerevolmente inferiore alla profilazione della strumentazione (dell'ordine di 1-5%). La qualità dei dati dipende ovviamente dalla frequenza di campionamento. Entrambe le forme di profilazione hanno un impatto diverso da zero, ma il campionamento è significativamente inferiore. –

1

Si potrebbe provare h3r3tic's xfProf, che è un profiler di campionamento. Non ho provato io stesso, ma quel ragazzo fa sempre cose interessanti :)

Dalla descrizione:

Se il programma viene campionato solo poche centinaia (o migliaia) volte al secondo, le prestazioni l'overhead non sarà evidente.

+0

Grazie. Questo dovrebbe essere un miglioramento (non l'ho ancora testato), anche se dice ancora che è necessario compilare senza ottimizzazioni, che probabilmente ha più di 2x perf. costo. – dsimcha

+0

@dsimcha: @torhu: ho appena controllato il sito xfProf. Sono triste. È costruito sugli stessi principi di gprof. Ecco perché questo mi rende triste: http://stackoverflow.com/questions/1777556/alternatives-to-gprof/1779343#1779343 –

2

My favorite method of profiling rallenta il programma modo modo verso il basso, e questo è OK. Eseguo il programma sotto il debugger, con un carico realistico, e poi lo interrompo manualmente. Quindi copio lo stack delle chiamate da qualche parte, come nel Blocco note. Quindi prende l'ordine di un minuto per raccogliere un campione. Quindi posso riprendere l'esecuzione, o è anche OK ricominciare dall'inizio per ottenere un altro campione.

Lo faccio 10 o 20 volte, abbastanza a lungo per vedere ciò che il programma sta effettivamente facendo da una prospettiva a muro. Quando vedo qualcosa che si presenta molto, quindi prendo più campioni fino a quando non si presenta di nuovo. Quindi mi fermo e lo studio in realtà studia cosa sta facendo e perché, che può richiedere 10 minuti o più. È così che scopro se quell'attività è qualcosa che posso sostituire con un codice più efficiente, cioè non era assolutamente necessario.

Vedete, non sono interessato a misurare quanto velocemente o lentamente sta andando. Posso farlo separatamente con forse solo un orologio.Sono interessato a scoprire quali attività richiedono una grande percentuale di tempo (non quantità, percentuale), e se qualcosa richiede una grande percentuale di tempo, questa è la probabilità che ogni stackshot la vedrà.

Per "attività" non intendo necessariamente dove il PC si blocca. Nel software realistico il PC è quasi sempre spento in un sistema o in una libreria di routine da qualche parte. In genere più importanti sono i siti di chiamata nel nostro codice. Se vedo, ad esempio, una serie di 3 chiamate che mostrano metà dei campioni di stack, rappresenta una buona caccia, perché se una di queste non è veramente necessaria e può essere eliminata, il tempo di esecuzione diminuirà di metà.

Se vuoi un manager sorridente, fallo una o due volte.

Anche in quello che penseresti sarebbero app di calcolo scientifico e matematico per la risoluzione dei numeri, in cui penseresti che l'ottimizzazione a basso livello e gli hotspot possano dominare il giorno, sai cosa trovo spesso? Le routine della libreria matematica sono che controllano gli argomenti, non eseguendo lo sgranamento. Spesso il codice non sta facendo quello che pensi che stia facendo, e non devi eseguirlo alla massima velocità per scoprirlo.

+0

Meno utile quando si dispone di un profilo piuttosto piatto in cui nessun componente richiede più del 2% del tempo di esecuzione da solo, ma devi in ​​qualche modo ottenere il tuo ciclo principale da 40ms a 33ms fissando cinquanta piccole cose. Ma questo è un caso piuttosto specializzato. – Crashworks

+0

Inoltre dovresti davvero dare un'occhiata ai moderni profilatori di campionamento. Continuo a raccomandarvelo non perché ritengo che il tuo metodo sia scarso, ma perché sono totalmente d'accordo con il tuo approccio e sono felice che ci siano strumenti automatici che possono farlo 1000 campioni al secondo. – Crashworks

+0

@Crashworks: Grazie. La mia esperienza è che si arriva al punto di avere piccole cose da ottimizzare dopo un processo di eliminazione di alcune cose piuttosto enormi che non si è mai immaginato fossero lì. Per quanto riguarda gli strumenti, penso che Zoom e LTProf abbiano l'idea giusta, ma come ho cercato di spiegare in precedenza, non è necessario un gran numero di campioni a meno che i problemi più grandi siano davvero molto piccoli. Inoltre, non conosco nessuno strumento che consenta di esaminare in dettaglio un campione rappresentativo e il contesto del programma in vigore al momento in cui è stato preso. Questo ti dà l'intuizione che i numeri non possono. –

Problemi correlati