Performance de démarrage de l'injection de dépendances

Question

Il m'a récemment été demandé de résoudre certains problèmes de performance dans une application créée avec le bloc d'application Composite UI de Microsoft - en particulier que cela prenait trop de temps à charger.

Ceci est construit autour de l'infrastructure d'injection de dépendance ObjectBuilder de Microsoft, qui utilise des attributs de réflexion/attributs pour enregistrer des classes. Le profilage indiquait qu'au démarrage, l'application passait beaucoup de temps à réfléchir, car ObjectBuilder analyse chaque type dans chaque assemblage chargé dans la recherche de choses à enregistrer.

Les autres environnements de DI semblent également utiliser des attributs, une configuration XML ou du code pur.
Il ne semble pas que les autres frameworks basés sur les attributs soient meilleurs, et je suis sceptique quant aux temps de démarrage quand des piles de XML doivent être analysées, etc. Les frameworks basés sur le code pur semblent être beaucoup plus rapides, mais ils sont aussi beaucoup moins flexibles, donc il ne semble pas vraiment y avoir un bon choix ...

Ceci m'a conduit à chercher pour les benchmarks de conteneurs DI, mais le seul que j'ai pu trouver est celui-ci: http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html.
Bien que ce soit un excellent benchmark, il ne mesure que la vitesse à laquelle vous pouvez créer 1 million d'objets en utilisant le conteneur. Je n'ai aucun intérêt à créer 1 million d'objets, je veux juste l'application pour lancer le plus rapidement possible, donc ce que je cherche est des informations sur DI Container démarrage coûts, que ce soit des billets de blog, des anecdotes, ou même quelque chose d'aussi simple que "voici un moyen de rendre ObjectBuilder plus rapide".

Merci à l'avance

Answer 1

Avez-vous essayé de mesurer les temps de démarrage lorsque toutes les assemblées a été NGEN'd? J'ai trouvé (au moins dans IronScheme), que cela aide beaucoup (dans mon cas de 1,5 sec à 0,1 sec) dans des scénarios de réflexion.

Answer 2

En le rendant plus rapide ...

Je pense qu'il ya probablement un moyen de mettre en cache le résultat de la mise en service. Peut-être que l'application passe un peu plus de temps à faire la réflexion puis à mettre en cache le résultat, mais lors de votre deuxième démarrage, si rien n'a changé, vous pouvez charger à partir du cache (ce qui pourrait être plus rapide). En ce qui concerne la nature de ce cache, il se peut que les objets soient sérialisés sur le disque. Comme la question "rien n'a changé", le démarrage pourrait regarder des sommes de contrôle.

Answer 3

Je ne connais pas ObjectBuilder, mais les structures d'injection de dépendance récentes prennent généralement en charge le chargement paresseux pour améliorer les performances de démarrage. Par exemple, voir Lazing Around with Autofac2.

Ou vous pouvez le faire manuellement comme dans l'exemple LazyOrderShipper de Ploeh.