Compact Framework e JIT. Quanto tempo potrebbe richiedere

Question

Abbiamo / abbiamo avuto un ritardo fantasma nella nostra app. Ciò è stato ricondotto all'inizializzazione di un singleton quando l'oggetto è stato toccato per la prima volta ed è stato incolpato di JIT. Non ne sono assolutamente convinto in quanto non esiste un meccanismo per misurare la JIT (o c'è?) E l'intero ritardo era di sette secondi. Sette secondi di JIT?!? Potrebbe essere reale?

In entrambi i casi ho difficoltà a incolpare cose che non si possono facilmente misurare. Quando ho dato un'occhiata alla questione qualche tempo fa, ho commentato un sacco di codice e ho visto il ritardo di sette secondi "salta". altrove nell'app. Suggerire che sta accadendo in qualche modo su un processo in background da qualche parte (e immagino che questo considererebbe JIT come una potenziale causa).

Solo per divertimento se ci fosse un oggetto statico che faceva riferimento a molti altri oggetti qualcuno ha una regola empirica per quanto tempo potrebbe richiedere la JIT? Qualcuno ha ulteriori riferimenti in modo che io possa capire di più sulla SIC, quindi ho la possibilità di sapere se la SIC sia o no responsabile di questo rallentamento?

Answer 1

Ho visto JIT impiegare davvero molto tempo (più di 1 secondo) in uno strano bug che aveva a che fare con oggetti con template all'interno di una collezione con template (vedi modifica sotto).

Ad ogni modo, il fatto che lo vedi " sposta " sicuramente mi indica che probabilmente non è questo il problema. Per provare a determinarlo definitivamente, guarderei usando RPM per vedere cosa sta succedendo subito prima e dopo il ritardo.

Il tempo JIT atteso è davvero nebuloso, poiché ci sono così tanti fattori che possono influenzarlo. La velocità del processore è ovvia, ma meno ovvi potrebbero essere cose come i supporti di archiviazione delle app e la pressione della memoria del dispositivo.

I supporti di archiviazione possono influire sulla velocità di JIT perché JITter deve estrarre l'IL dal supporto quando ha bisogno di JIT e se l'estrazione è lenta, JITting sarà lento.

La pressione della memoria è molto dura e può avere gravi ripercussioni su un dispositivo CE. Il problema qui è che quando inizi a esaurire la memoria, EE inizierà a lanciare il codice JITted durante la raccolta - tutto tranne lo stack di chiamate. Ora, se sei in una routine che, ad esempio, chiama alcuni elementi di lavoro o di supporto o ha un thread in esecuzione, allora quel metodo di supporto potrebbe essere lanciato, JITted, pitched JITted, ecc. Questo è indicato come " ; thrash ".

Identificare quest'ultimo è abbastanza facile con RPM (risolverlo potrebbe non essere così semplice). Osserva la quantità di codice lanciato per aumentare frequentemente e cerca una forte correlazione tra un aumento del numero di passi e i tuoi blocchi percepiti.

Modifica: ho finalmente trovato la descrizione del bug qui .

Answer 2

I timer JIT (e GC) ecc. sono disponibili qui:

Contatori delle prestazioni in .NET Compact Framework ( http://msdn.microsoft.com/en-us/library/ms172525 aspx )

Monitoraggio delle prestazioni dell'applicazione su .NET Compact Framework Parte I - Abilitazione dei contatori delle prestazioni ( http://blogs.msdn.com/davidklinems/archive/2005/10/04/476988.aspx )

Analisi delle prestazioni dell'applicazione del dispositivo con .Net Compact Framework Remote Performance Monitor ( http://blogs.msdn.com/stevenpr/archive/2006/04/17/577636.aspx )

Contatori delle prestazioni in .NET Framework
( http://msdn.microsoft.com/en- us / library / w8f5kw2e (VS.80) aspx )

Saluti, Tamberg