J’entends constamment comment le mauvais reflet consiste à utiliser. Alors que j’ai généralement éviter la réverbération et rarement trouver des situations où il est impossible de résoudre mon problème sans elle, je me demandais...
Pour ceux qui ont utilisé la réflexion dans les applications, on vous mesuré les performances et, est-ce vraiment si mauvais ?
Dans son discours La Performance des choses tous les jours, Jeff Richter montre qu’appel d’une méthode par réflexion est sur 1000 fois plus lent que d’appeler il normalement.
Astuce de Jeff : Si vous devez appeler la méthode plusieurs fois, utilisez la réflexion une fois pour le trouver, puis affectez-la à un déléguéet ensuite appeler le délégué.
Il est. Mais ça dépend de ce que vous essayez de faire.
J'ai utiliser la réflexion pour charger dynamiquement des assemblées (plugins) et sa performance "sanction" n'est pas un problème, puisque l'opération est quelque chose que je ne lors du démarrage de l'application.
Toutefois, si vous êtes en réfléchissant à l'intérieur d'une série de boucles imbriquées, de réflexion, invite chacun, je dirais que vous devriez revoir votre code :)
Pour "un certain temps", la réflexion est tout à fait acceptable et vous n'aurez pas l'avis de tout retard ou problème avec elle. C'est un mécanisme très puissant et il est encore utilisé par .NET, donc je ne vois pas pourquoi vous ne devriez pas essayer.
La réflexion de la performance dépendra de la mise en œuvre (les appels doivent être mis en cache par exemple: entity.GetType().GetProperty("PropName")). Depuis plus de la réflexion que je vois sur une base quotidienne est utilisé pour remplir des entités à partir des données de lecteurs ou d'autres type de référentiel des structures, j'ai décidé de performance de référence spécifiquement à la réflexion, lorsqu'il est utilisé pour obtenir ou définir l'une des propriétés des objets.
J'ai mis au point un test qui je pense est juste, car il met en cache tous les répétant les appels et les seules fois où le réel SetValue ou GetValue appel. Tout le code source pour le test de performance est en bitbucket: https://bitbucket.org/grenade/accessortest. L'examen sont les bienvenues.
La conclusion je suis venu, c'est qu'il n'est pas pratique et ne fournit pas de notables améliorations de performance à la suppression de la réflexion dans une couche d'accès aux données qui revient à moins de 100 000 lignes à un moment où la réflexion de la mise en œuvre est bien fait.
Le graphique ci-dessus illustre la sortie de mon petit benchmark et montre que les mécanismes qui dépassent le reflet, seulement faire sensiblement après 100 000 cycles de marque. La plupart des Lad seulement le retour de plusieurs centaines ou peut-être des milliers de lignes à la fois et à ces niveaux de réflexion effectue très bien.
Mon expérience pertinente était de l'écriture de code pour comparer deux entités de données de même type dans un grand modèle d'objet de propriété-sage. Ai eu de travail, il a essayé, a couru comme un chien, évidemment.
J'ai été découragé, puis une nuit réalisé que sans changer la logique, je pourrais utiliser le même algorithme pour générer automatiquement des méthodes pour faire la comparaison, mais de manière statique aux propriétés. Il a fallu peu de temps pour adapter le code à cette fin, et j'ai eu la capacité de faire de profond bien-sage comparaison des entités statiques de code qui peut être mis à jour au clic d'un bouton chaque fois que le modèle de l'objet modifié.
Mon point: Dans les conversations avec les collègues depuis que j'ai plusieurs fois souligné que l'utilisation de leur réflexion pourrait être de générer automatiquement le code à compiler plutôt que d'effectuer d'exécution des opérations et c'est souvent utile d'examiner.
Pas massivement. Je n'ai jamais eu un problème avec elle dans le développement de postes de travail, à moins que, comme Martin, vous l'utilisez dans un drôle de lieu. J'ai entendu beaucoup de gens ont totalement irrationnelle des craintes au sujet de sa performance dans le développement de postes de travail.
Dans le Compact Framework (dont je suis habituellement en) cependant, il est à peu près anethema et doivent être évités comme la peste dans la plupart des cas. Je peux encore sortir avec elle à l'aide rarement, mais je dois être très prudent avec son application qui est beaucoup moins amusant. :(
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
