.NET ensemble cache/ngen/jit comportement d'échauffement et de refroidissement d'image

Question

J'ai un programme de méthode d'entrée (IME) construit avec DLL C# .NET 2.0 via C++/CLI. Comme un IME est toujours attaché à une autre application, la DLL C# .NET ne semble pas capable d'éviter le changement d'adresse de l'image. Bien que j'aie appliqué ngen pour créer une image native de cette DLL C# .NET 2.0 et l'ai installée dans Global Assembly Cache, elle ne s'est pas améliorée beaucoup, environ 12 secondes. jusqu'à 9 sec. sur un PC de niveau PIII lent.

Par conséquent j'utilise une petite application, qui charge tous les composants référencés par la DLL C# .NET au démarrage, pour "chauffer" l'image native de cette DLL. Cela fonctionne bien pour accélérer le temps de chargement à 0,5 secondes.

Cependant, cela n'a fonctionné que pendant un certain temps. Environ 30 minutes plus tard, il semble "refroidir" à nouveau.

Existe-t-il un moyen de contrôler le comportement du GAC ou de l'image native pour qu'elle soit toujours "chaude"? Est-ce exactement un problème de rebasage d'adresse d'image?

Answer 1

Je pense que les bibliothèques de frameworks et le CLR lui-même sont probablement dans le cache de Windows.

Vous trouverez peut-être qu'une petite application qui est restée en arrière-plan, peut-être écrire un octet dans un fichier toutes les minutes (ou une autre tâche inutile fournissant assez d'activité pour conserver tous les fichiers pertinents dans le cache) faire assez pour garder les choses "chaudes".

Cela vaut la peine d'essayer - cela ne devrait pas prendre trop de temps pour écrire.