Comment précharger les assemblages .net

Question

Dans mon travail, nous développons différentes applications utilisant .net framework 4. Toutes les applications utilisent des assemblages communs que nous avons développés, par exemple la couche de données dans data.dll. Ces applications résident sur un lecteur réseau et sont lancées directement à partir de là.

La plupart des grandes applications mettent un certain temps, comme peut-être 4-5 secondes, pour lancer la première fois (démarrage à froid). Les lancements suivants sont beaucoup plus rapides, presque instantanés. Je ne pense pas que cela ait à voir avec le réseau, puisque le plus gros assemblage se situe autour de 900Ko et que nous utilisons un réseau Gigabit.

Je voudrais créer un service qui démarre au démarrage de l'ordinateur et qui charge tous les assemblages .net sous un répertoire spécifique. J'espère que lorsque l'utilisateur lancera un programme, tous les assemblages nécessaires seront déjà chargés et 'JITed', donc le démarrage devrait être plus rapide.

Je sais comment créer un service, mais je voudrais savoir si cela pourrait fonctionner parce que ma compréhension du CLR est assez limitée ... Aussi, ferait quelque chose comme Assembly.LoadFrom (fileName) de précharger le assemblées? Si je ne lance aucun programme pendant un certain temps, reste-t-il chargé ou se décharge-t-il après un certain temps? Que se passe-t-il si je change un assemblage déjà chargé?

Fondamentalement, je voudrais faire quelque chose comme le OpenOffice Quick starter, mais pour notre propre cadre d'application.

Merci à tous !!!

--- EDIT ---
This is interresting... semble aller dans le bon sens, mais pas sûr de tout comprendre ...

Answer 1

Vous avez plusieurs options. En supposant que les assemblys communs ont des noms forts, ils peuvent être placés dans le Global Assembly Cache (GAC) de l'utilisateur. Si ces assemblages sont stables, vous pouvez avoir du code natif généré avec ngen.exe, ce qui vous donnera le "pré-JIT'd" dont vous avez besoin. Google GAC et ngen pour plus d'informations.

Modifier après la mise à jour de la question:

ensembles de chargement de la façon dont vous êtes à la recherche est pas nécessairement le moyen le plus efficace - ces assemblées vont vivre dans la mémoire de votre service aussi longtemps que le service est autour, et que peut ou peut ne pas être un fardeau sur la machine client. Je crois qu'une combinaison de GAC'ing et ngen'ing vos assemblys est le meilleur pari, et ces deux étapes peuvent être automatisées (en supposant que le service fonctionne avec les permissions appropriées) en récupérant les assemblages et en rendant externes appelle gacutil.exe et ngen.exe en utilisant la classe System.Diagnostics.Process.

Page MSDN pour ngen.exe

Page MSDN pour gacutil.exe

la page MSDN pour la Process class

Answer 2

Qu'est-ce que vous voulez est NGEN, qui précompile les assemblées pour vous. Je pense que le problème que vous allez avoir est que les assemblages du réseau, et potentiellement être chargé pour différentes architectures CPU. NGEN doit être exécuté sur l'ordinateur de destination lors de la compilation et de l'optimisation de l'architecture spécifique utilisée par l'ordinateur.

Ce que vous pourriez envisager est de donner aux assemblys des noms forts et de les installer dans le GAC sur chaque ordinateur.

Je ne pense pas que l'approche que vous envisagez va fonctionner, je pense que vous allez les charger dans le processus de service et une fois qu'ils sont libérés, ils seront nettoyés par le système et le net le résultat ne sera pas une augmentation de la vitesse.

Answer 3

Vous pouvez pré-assemblées jit par programme en utilisant la technique décrite dans l'article suivant: Pre-compile (pre-JIT) your assembly on the fly, or trigger JIT compilation ahead-of-time.

Cependant, je ne pense pas que les jitting en un seul processus aura un effet sur un autre (pas sûr à ce sujet). Une solution possible consiste à démarrer votre application sur l'ordinateur avec des options de ligne de commande indiquant qu'elle ne devrait que préjecter des assemblys et ne rien faire d'autre. Lorsque l'utilisateur lancera l'application, il dira au processus en cours d'exécution de démarrer sa fonctionnalité par défaut.

Answer 4

Vous savez déjà que la compilation JIT n'est pas le problème, cela ralentirait également le second démarrage. Tout ce que vous avez à faire est d'obtenir les DLL dans le cache du système de fichiers. Alors que lorsque vous démarrez le programme plus tard, il utilisera la copie de cette DLL à partir du cache au lieu de creuser à travers le lecteur réseau attaché pour le trouver. C'est ce qui prend du temps. Office Quick Start utilise la même astuce. Je ne sais pas qui va gagner si tout ce matériel préchargé ne correspond plus. Il suffit de créer une application Winforms, donc vous n'obtenez pas une fenêtre, et appelez Assembly.Load() pour obtenir les assemblys chargés, File.ReadAllBytes() pour vous assurer que tout le contenu est dans le cache. Mettez un raccourci vers ce programme dans le dossier Démarrage. Ce montage que vous avez mentionné est assez grand pour obtenir un coup de pouce dans le démarrage à chaud de Ngen.exe. Cela doit être exécuté sur chaque poste de travail individuel.