2009-01-20 12 views
2

Nous avons eu/eu un délai fantôme dans notre application. Ceci a été tracé à l'initialisation d'un singleton quand l'objet a été touché pour la première fois et a été blâmé sur JIT. Je ne suis pas totalement convaincu par cela car il n'y a pas de mécanisme pour mesurer JIT (ou est-ce qu'il y en a?) Et le délai entier était de sept secondes. Sept secondes de JIT?!? Cela pourrait-il être réel?Compact Framework et JIT. Combien de temps cela a-t-il pu prendre?

De toute façon, j'ai du mal à blâmer les choses qu'on ne peut pas facilement mesurer. Quand j'ai jeté un coup d'œil sur le problème il y a quelque temps, j'ai commenté un tas de code et regardé le "second saut" de sept secondes ailleurs dans l'application. Suggérer qu'il se passe quelque part sur un processus de fond quelque part (et je suppose que cela pourrait considérer JIT comme une cause potentielle). Juste pour le plaisir, s'il y avait un objet statique qui faisait référence à beaucoup d'autres objets, quelqu'un a-t-il une règle de base pour combien de temps le JAT pourrait prendre? Quelqu'un a-t-il d'autres références pour que je puisse en savoir plus sur le JIT afin que j'aie une chance d'apprendre si JIT est/était à blâmer pour ce ralentissement?

Répondre

1

J'ai seulement vu JIT prendre beaucoup de temps (plus d'une seconde) dans un bogue bizarre qui avait à faire avec des éléments de modèles dans une collection de modèles (voir la modification ci-dessous). En tout cas, le fait que vous le voyiez "bouger" m'indique définitivement que ce n'est probablement pas le problème. Pour essayer de le déterminer définitivement, je regarderais en utilisant RPM pour voir ce qui se passe juste avant et après le délai.

Le temps d'attente d'attente est une chose très nébuleuse, car il y a tellement de facteurs qui peuvent l'affecter. La vitesse du processeur est évidente, mais les choses comme les supports de stockage d'applications et la pression de la mémoire de l'appareil sont moins évidentes.

Le média de stockage peut affecter la vitesse JIT parce que le JITter doit tirer l'IL du média quand il a besoin de le JITTER, et si le tirer est lent, JITting sera lent.

La pression de la mémoire est difficile et peut avoir de graves répercussions sur un appareil CE. Le problème ici est que lorsque vous commencez à manquer de mémoire, l'EE commence à lancer le code JITTED pendant la collecte - tout sauf la pile d'appels. Maintenant, si vous êtes dans une routine qui, par exemple, appelle un agent ou un assistant, ou a un thread en cours d'exécution, alors cette méthode d'assistance pourrait être lancée, JITted, pitched JITted, etc. débattre."

L'identification de ce dernier est assez facile avec RPM (la fixation peut ne pas être si facile). Regardez la quantité de code lancée pour augmenter fréquemment et cherchez une forte corrélation entre une augmentation du nombre d'emplacements et vos blocages perçus.

Édition: J'ai finalement trouvé the bug description here.

+0

Merci pour cette description de bug. v.Interesting et un peu drôle aussi. – Quibblesome

1

JIT (et GC) minuteries etc. peuvent être trouvés ici:

compteurs de performance dans le Compact Framework .NET (http://msdn.microsoft.com/en-us/library/ms172525.aspx)

surveillance des performances des applications sur le .NET Compact Framework Partie I - Activation compteurs de performance (http://blogs.msdn.com/davidklinems/archive/2005/10/04/476988.aspx)

Dispositif d'analyse de la performance des applications avec le .Net Compact Framework Analyseur de performances à distance (http://blogs.msdn.com/stevenpr/archive/2006/04/17/577636.aspx)

Compteurs de performance dans le.NET Framework
(http://msdn.microsoft.com/en-us/library/w8f5kw2e(VS.80).aspx)

Cordialement, Tamberg