Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Aggiornamento: novembre 2007
Un profiler è un strumento che consente di monitorare l'esecuzione di un'altra applicazione. Un profiler di Common Language Runtime è una DLL costituita da funzioni che ricevono e inviano messaggi a CLR utilizzando l'API di analisi. La DLL del profiler viene caricata in fase di esecuzione da CLR.
Gli strumenti di analisi tradizionali si basano sulla misurazione dell'esecuzione dell'applicazione, ovvero del tempo impiegato da ciascuna funzione oppure dell'utilizzo della memoria nel tempo da parte dell'applicazione. L'API di analisi fa riferimento a una classe più ampia di strumenti di diagnostica, quali utilità di code coverage e persino supporti di debug avanzati, tutti utilizzati per fini diagnostici. L'API di analisi non si limita a misurare l'esecuzione di un'applicazione, ne esegue anche il monitoraggio. Per questa ragione, non deve mai essere utilizzata dall'applicazione stessa e l'esecuzione dell'applicazione non deve dipendere dal profiler (né essere influenzata da questo).
L'analisi di un'applicazione CLR richiede un maggiore supporto rispetto all'analisi del codice macchina compilato in modo tradizionale, in quanto CLR introduce concetti quali domini dell'applicazione, Garbage Collection, gestione delle eccezioni gestite, compilazione del codice JIT (tramite la conversione del codice MSIL in codice macchina nativo) e funzionalità simili. I meccanismi di analisi convenzionali non sono in grado di identificare o fornire informazioni utili su queste funzionalità. L'API di analisi fornisce queste informazioni mancanti in modo efficiente, con un impatto minimo sulle prestazioni di CLR e dell'applicazione analizzata.
La compilazione JIT in fase di esecuzione offre buone possibilità di analisi. L'API di analisi consente a un profiler di modificare il flusso di codice MSIL in memoria per una routine prima che venga compilato tramite JIT. In tal modo, il profiler può aggiungere dinamicamente codice di strumentazione a routine specifiche per le quali è richiesta un'indagine più approfondita. Sebbene questo approccio sia possibile negli scenari convenzionali, è molto più semplice da implementare per CLR utilizzando l'API di analisi.
API di analisi
In genere, l'API di analisi viene utilizzata per scrivere un Code Profiler, ovvero un programma che consente di monitorare l'esecuzione di un'applicazione gestita.
L'API di analisi viene utilizzata da una DLL del profiler caricata nello stesso processo dell'applicazione che si sta analizzando. La DLL del profiler implementa un'interfaccia di callback (ICorProfilerCallback in .NET Framework versione 1.0 e 1.1, ICorProfilerCallback2 nella versione 2.0). CLR chiama i metodi di quella interfaccia per notificare al profiler gli eventi nel processo analizzato. Il profiler può eseguire un callback nel runtime utilizzando i metodi delle interfacce ICorProfilerInfo e ICorProfilerInfo2 per ottenere informazioni sulla stato dell'applicazione analizzata.
Nota
Solo la parte della soluzione del profiler relativa alla raccolta dei dati deve essere in esecuzione nello stesso processo dell'applicazione analizzata. L'interfaccia utente e l'analisi dei dati devono essere eseguite in un processo separato.
Nell'illustrazione seguente viene mostrata la modalità di interazione della DLL del profiler con l'applicazione che si sta analizzando e con CLR.
Architettura di analisi
.png)
Interfacce di notifica
ICorProfilerCallback e ICorProfilerCallback2 possono essere considerate interfacce di notifica. Tali interfacce sono costituite da metodi quali ClassLoadStarted, ClassLoadFinishede JITCompilationStarted. Ogni volta che CLR carica o scarica una classe, compila una funzione e così via, chiama il metodo corrispondente nell'interfaccia ICorProfilerCallback o ICorProfilerCallback2 del profiler.
Ad esempio, un profiler potrebbe misurare le prestazioni del codice tramite due funzioni di notifica: FunctionEnter2 e FunctionLeave2. Il profiler imposta un timestamp per ogni notifica, accumula risultati e restituisce un elenco in cui sono indicate le funzioni che hanno utilizzato maggiormente la CPU o che hanno richiesto più tempo durante l'esecuzione dell'applicazione.
Interfacce di reperimento delle informazioni
Le altre interfacce principali coinvolte nell'analisi sono ICorProfilerInfo e ICorProfilerInfo2. Il profiler chiama queste interfacce secondo necessità per ottenere una maggiore quantità di informazioni per l'analisi. Ad esempio, ogni volta che CRL chiama la funzione FunctionEnter2, fornisce un identificatore della funzione. Il profiler può ottenere ulteriori informazioni su quella funzione chiamando il metodo ICorProfilerInfo2::GetFunctionInfo2 per scoprire la classe padre della funzione, il nome e così via.