come funziona un C# profiler?

Question

Sono curioso di sapere come funziona un tipico profiler C#?

Esistono appositi ganci nella macchina virtuale?

E 'facile da leggere il codice di byte per le chiamate di funzione e iniettare le chiamate per avviare/arrestare il timer?

O è davvero difficile ed è per questo la gente paga per gli strumenti per fare questo?

(come nota a margine trovo un po 'interessante bec E' così raro - google manca la barca completamente sulla ricerca "how does a c# profiler work?" non funziona affatto - i risultati sono circa condizionatori d'aria ...)

Answer 1

C'è un CLR Profiler gratuito di Microsoft, versione 4.0.

https://www.microsoft.com/downloads/en/details.aspx?FamilyID=be2d842b-fdce-4600-8d32-a3cf74fda5e1

A proposito, c'è una bella sezione nel documento CLR Profiler che descrive come funziona, nel dettaglio, pagina 103. C'è fonte come parte della distro.

Answer 2

1) Non esiste una cosa "tipica". Le persone raccolgono informazioni sul profilo con una varietà di mezzi: campionamento temporale del PC, ispezione delle tracce dello stack, acquisizione dei conteggi di esecuzione di metodi/istruzioni/istruzioni compilate, inserimento di sonde nel codice per raccogliere i conteggi e facoltativamente chiamata contesti per ottenere i dati del profilo in un contesto di chiamata base. Ognuna di queste tecniche potrebbe essere implementata in modi diversi.

2) C'è profiling "C#" e profiling "CLR". Nel mondo MS, è possibile definire il CLR e le posizioni delle istruzioni CLR back-translate al codice C#. Non so se Mono usa lo stesso set di istruzioni CLR; in caso contrario, non è possibile utilizzare il profiler MS CLR; dovresti usare un profiler IL mono. Oppure, è possibile utilizzare il codice sorgente C# per raccogliere i dati di profilazione e quindi compilare/eseguire/raccogliere i dati su MS, Mono o il compilatore C# compatibile di qualcuno o C# in esecuzione in sistemi embedded come WinCE dove lo spazio è prezioso e le funzioni come i built-in CLR tendono ad essere tralasciate.

Un modo per utilizzare il codice sorgente è quello di utilizzare trasformazioni da origine a fonte, per mappare il codice dallo stato iniziale al codice che contiene il codice di raccolta dati e il programma originale. Questo paper on instrumenting code to collect test coverage data mostra come un sistema di trasformazione del programma può essere utilizzato per inserire sonde di copertura del test inserendo istruzioni che impostano i flag booleani specifici del blocco quando viene eseguito un blocco di codice. Un conteggio del profiler sostituisce le istruzioni di controincremento per quelle sonde. Un profiler di temporizzazione inserisce calcoli clock-snapshot/delta per quelle sonde. Il nostro C# Profiler implementa sia il conteggio sia il profilo temporale per il codice sorgente C# in entrambe le direzioni; raccoglie anche i dati del grafico delle chiamate utilizzando sonde più sofisticate che raccolgono il percorso di esecuzione. In questo modo può produrre dati di temporizzazione sui grafici delle chiamate in questo modo. Questo schema funziona ovunque tu possa mettere le mani su un valore di tempo di risoluzione decente a metà.

Answer 3

E 'facile eseguire la scansione del codice di byte per chiamate di funzione e iniettare chiamate start/stop timer?

O è davvero difficile ed è per questo la gente paga per gli strumenti per fare questo?

Iniezione di chiamate è abbastanza difficile che gli strumenti sono necessari per farlo.

non solo è difficile, è un modo molto indiretto, per trovare i colli di bottiglia. Il motivo è che un collo di bottiglia è uno o un piccolo numero di istruzioni nel codice che sono responsabili di una buona percentuale di tempo speso, tempo che potrebbe essere ridotto in modo significativo - cioè non è veramente necessario, cioè è uno spreco. SE puoi dire il tempo medio compreso di una delle tue routine (compreso il tempo di IO), e SE puoi moltiplicarlo di quante volte è stato chiamato, e dividere per il tempo totale, puoi dire quale percentuale di tempo il la routine prende. Se la percentuale è piccola (come il 10%) probabilmente avete problemi più grandi altrove. Se la percentuale è maggiore (come dal 20% al 99%) si potrebbe avere un collo di bottiglia all'interno della routine. Quindi ora devi fare all'interno della routine per questo, guardando le cose che chiama e quanto tempo loro prendere. Inoltre, si vuole evitare di essere confusi dalla ricorsione (il bugaboo dei grafici delle chiamate).

Ci sono profiler (come Zoom per Linux, Shark, &) che funzionano su un principio diverso. Il principio è che c'è uno stack di chiamate di funzioni e durante tutto il tempo che una routine è responsabile (sia che lavori o aspetti che altre routine eseguano il lavoro richiesto) è nello stack. Quindi, se è responsabile per il 50% del tempo (diciamo), allora è il tempo che è in pila, indipendentemente da quante volte è stato chiamato, o quanto tempo è occorso per chiamata. Non solo la routine è in pila, ma anche le linee specifiche di codice che costano il tempo sono in pila. Non hai bisogno di cercarli. Un'altra cosa che non ti serve è la precisione della misurazione. Se si prendessero 10.000 campioni di stack, le linee colpevoli sarebbero misurate a 50 +/- 0,5 percento. Se si prendessero 100 campioni, sarebbero misurati come 50 +/- 5 percento. Se si prendessero 10 campioni, sarebbero misurati come 50 +/- 16 percento. In ogni caso li trovi, e questo è il tuo obiettivo. (E la ricorsione non ha importanza. Tutto ciò significa che una determinata linea può apparire più di una volta in un campione di pila.)

Su questo argomento, c'è molta confusione. In ogni caso, i profiler che sono più efficaci nel trovare i colli di bottiglia sono quelli che campionano lo stack, in tempo di wall-clock, e riferiscono percentuale per riga. (Questo è facile da vedere se certi myths about profiling sono messi in prospettiva.)

Answer 4

Questo è un link ad un lungo articolo che discute entrambi i metodi di campionamento e strumentazione:

http://smartbear.com/support/articles/aqtime/profiling/