Generazione di codice nell'API di profilatura
In questo argomento vengono illustrati il flusso di codice MSIL (Microsoft Intermediate Language) nel codice nativo e il modo in cui un profiler può controllare la generazione del codice.
Generazione automatica e generazione manuale del codice
Il codice MSIL in un assembly .NET Framework può essere compilato nel codice nativo in uno dei due modi descritti di seguito:
Compilazione manuale: lo strumento Native Image Generator (NGen.exe) può essere utilizzato per creare un'immagine nativa.
Compilazione automatica: Common Language Runtime può effettuare la compilazione JIT in fase di esecuzione.
NGen.exe e il compilatore JIT forniscono flag che controllano la generazione del codice.
Quando un assembly viene caricato, CLR cerca innanzitutto un'immagine nativa per l'assembly. Se non riesce a trovare un'immagine nativa con il set di flag di generazione del codice appropriato, CLR utilizzerà la compilazione JIT per le funzioni dell'assembly, dal momento che sono necessarie durante l'esecuzione. La compilazione JIT per alcune delle funzioni dell'assembly potrebbe essere utilizzata persino quando un'immagine nativa viene trovata e caricata.
Controllo del profiler sulla generazione del codice
Il profiler utilizza i flag nella tabella riportata di seguito per controllare la generazione del codice.
Flag |
Effetto |
|---|---|
COR_PRF_USE_PROFILE_IMAGES |
Richiede la versione 2.0 di .NET Framework. Fa sì che la ricerca delle immagini native inizi dalle immagini ottimizzate del profiler (ngen /profile). Se la ricerca non riesce a trovare un'immagine nativa ottimizzata del profiler per un assembly specificato, CLR utilizzerà la compilazione JIT per i metodi di quell'assembly, se necessario. Non ha effetto sul codice compilato tramite JIT. |
COR_PRF_DISABLE_INLINING |
Non ha effetto sulla ricerca dell'immagine nativa. Nella compilazione JIT, disabilita l'inlining. Tutte le altre ottimizzazioni rimangono attive. |
COR_PRF_DISABLE_OPTIMIZATIONS |
Non ha effetto sulla ricerca dell'immagine nativa. Nella compilazione JIT, disabilita tutte le ottimizzazioni, incluso l'inlining. |
COR_PRF_MONITOR_ENTERLEAVE |
Fa sì che la ricerca delle immagini native inizi dalle immagini ottimizzate del profiler (ngen /profile). Nella compilazione JIT, inserisce hook di ingresso/uscita nel codice generato. |
COR_PRF_MONITOR_CODE_TRANSITIONS |
Fa sì che la ricerca delle immagini native inizi dalle immagini ottimizzate del profiler (ngen /profile). Nella compilazione JIT, inserisce hook nei punti di transizione gestiti/non gestiti. |
Profiler e immagini native
Quando NGen.exe crea un'immagine nativa, esegue gran parte delle operazioni effettuate in genere da CLR in fase di esecuzione (ad esempio, il caricamento delle classi e la compilazione delle funzioni). Di conseguenza, nei casi in cui il lavoro sia stato eseguito nella fase NGen, i callback del profiler seguenti non saranno ricevuti in fase di esecuzione:
Immagini native ottimizzate del profiler
La creazione di un'immagine nativa con NGen.exe attiva un set di flag di generazione del codice che semplifica l'analisi dell'immagine, nel modo indicato di seguito:
Gli hook di ingresso/uscita vengono inseriti nel codice.
Gli hook di transizione gestiti/non gestiti vengono inseriti nel codice.
Nel momento in cui ogni funzione nell'immagine nativa viene richiamata per la prima volta, vengono generate le notifiche ICorProfilerCallback::JITCachedFunctionSearchStarted e ICorProfilerCallback::JITCachedFunctionSearchFinished.
Nel momento in cui ogni classe nell'immagine nativa viene utilizzata per la prima volta, vengono generate le notifiche ICorProfilerCallback::ClassLoadStarted e ICorProfilerCallback::ClassLoadFinished.
Considerazioni sulle prestazioni
Il metodo utilizzato per profilare l'applicazione generata da NGen dipende da due considerazioni: i dati che è necessario acquisire e l'effetto degli hook di analisi incorporati sull'applicazione.
Come illustrato in precedenza in questo argomento, esistono due scenari di analisi NGen di base:
Immagini native normali (immagini generate da NGen senza hook di analisi): queste immagini non provocano alcun sovraccarico di analisi. Tuttavia, i callback di caricamento/scaricamento delle classi non sono disponibili per le immagini native normali. Per gestire questa situazione, un profiler che non desidera richiedere immagini native ottimizzate del profiler dovrà raccogliere i dati sugli FunctionID o sugli ClassID nel momento in cui vengono rilevati gli ID. Ad esempio, un profiler di campionamento non rileverà un FunctionID quando viene compilato tramite JIT per la prima volta o caricato da un'immagine generata da NGen, in quanto i callback di caricamento/scaricamento delle classi non vengono generati per le immagini normali create tramite NGen. Il profiler rileverà l'FunctionID successivamente, quando verrà mostrato che il processo era in esecuzione in un puntatore all'istruzione all'interno del corpo del codice compilato della funzione. In tal caso, il profiler potrà richiedere informazioni sulla funzione durante il campionamento oppure registrare l'FunctionID o il relativo token di metadati associato per eseguire la query in un secondo momento. Pertanto, il profiler richiederà informazioni sull'FunctionID o sull'ClassID solo all'ultimo momento possibile (quando viene rilevato che l'ID è effettivamente in uso) piuttosto che al momento della creazione dell'ID.
Immagini native ottimizzate del profiler (immagini generate da NGen con hook di analisi incorporati): queste immagini sono più grandi e differiscono notevolmente dalle immagini normali. Inoltre, il comportamento dell'applicazione potrebbe essere diverso se include hook del profiler. Pertanto, le immagini native ottimizzate del profiler devono essere utilizzate solo se le possibili conseguenze (sovraccarico) sulle prestazioni e sul funzionamento sono accettabili.