Réflexion: La réflexion est-elle toujours «mauvaise» ou «lente»? Qu'est-ce qui a changé avec la réflexion depuis 2002?

J'ai remarqué qu'en traitant des expressions ou des arbres d'expression, j'utilise beaucoup la réflexion pour définir et obtenir des valeurs dans les propriétés et ce que vous avez. Il m'est venu à l'esprit que l'utilisation de la réflexion semble devenir de plus en plus courante. Des choses comme DataAnotations pour validation, attributs ORM de lourds, etc. me reste à se demander: Qu'est - ce qui a changé depuis les jours il y a des années et des années quand je l' habitude d'être dit d'éviter la réflexion , si possible?

Alors quoi, si quelque chose a changé? Est-ce juste la vitesse des machines? Y a-t-il eu des changements dans le cadre pour accélérer la réflexion?

Ou rien n'a vraiment changé? Est-il toujours "mauvais" ou "lent" d'utiliser la réflexion?

.net reflection

— blesh
source

La réflexion sera toujours plus lente que les appels directs, car vous devez effectuer plusieurs étapes pour rechercher et vérifier que ce que vous appelez existe.

— Michael K

C'était toujours mauvais ... Bien sûr, parfois, vous n'avez pas le choix, c'est au programmeur de savoir quand ces temps sont, et de l'éviter autrement.

— Ramhound

Effectuer une réflexion avec gettype pour extraire un élément d'une énumération est encore 30 fois plus rapide que de lever une exception avec Enum.Parse (). La réflexion gagne donc parfois.

— Brain2000

Réponses:

La réflexion n'est ni mauvaise, ni lente. C'est simplement un outil. Comme tous les outils, il est très précieux pour certains scénarios, pas aussi précieux pour d'autres.

Si les performances sont vraiment un problème, vous pouvez toujours utiliser une bibliothèque comme FasterFlect .

Lectures complémentaires
Si la réflexion est inefficace, quand est-elle la plus appropriée?

— Robert Harvey
source

Ou dynamic- apparemment un ordre de grandeur plus rapide que la réflexion.

— Odé le

La performance n'est pas du tout un problème. Je me souviens très bien que les gens avaient évité la réflexion en 2002 comme si c'était la peste. Je me demande ce qui a changé depuis.

— blesh

@blesh: Rien. Les gens le connaissent mieux et en ont moins peur.

— Robert Harvey

Je pourrais tout "descendre de ma pelouse" ici et dire que Lisp avait eu cela bien avant que la POO n'existe ...

— Michael K

C'est suffisant. Je me demandais simplement si ce sont les augmentations de vitesse des machines au cours des dix dernières années qui ont fait la différence ou si des modifications ont été apportées au système. La réflexion a amélioré les performances.

— blesh

La raison pour laquelle les gens hésitent à utiliser la réflexion inutilement n'est pas la performance: oui, il y a un surcoût à utiliser la réflexion, mais souvent, résoudre le problème sans cela nécessite une approche différente avec une complexité comparable, et même si ce n'est pas le cas, le surcoût est rarement significatif (en particulier pour le développement au niveau de l'application).

À l'aide de la réflexion, certaines hypothèses importantes que l'on peut normalement émettre à propos du code source sont rompues et les outils tels que «Rechercher toutes les références» cessent de fonctionner de manière fiable. La réflexion supprime également la plupart de la sécurité de type que le compilateur applique en C #, par exemple, et la plupart des erreurs de programmation qu'un système de type intercepterait et traduirait normalement en erreurs de compilation, deviennent maintenant des erreurs d'exécution au mieux ou des bogues très obscurs au pire.

Alors pourquoi les gens utilisent-ils la réflexion? Autrement dit, car malgré les problèmes décrits ci-dessus, c'est un outil très précieux. Avec la réflexion, certains des avantages de la programmation dynamique peuvent être obtenus dans un langage statique et strictement typé comme C #, et les langages de programmation dynamiques ont récemment montré leurs mérites, en particulier dans le domaine de la programmation Web - PHP, Javascript et Python bien en évidence. , tous utilisent la frappe dynamique et se sont révélés être de bons ajustements pour la programmation Web. Mais comme le langage est toujours C #, vous pouvez choisir de conserver la plupart de votre application dans un idiome OOP strictement typé et d'écrire la petite partie où le comportement dynamique fait vraiment une différence avec la réflexion.

Un exemple typique est lorsque vous devez exposer des méthodes en tant qu'appels de service Web (en utilisant un protocole non encore intégré à .NET). L'approche OOP strictement typée fonctionne, mais elle est trop restrictive et maladroite. Mais si vous utilisez la réflexion pour mapper les appels aux méthodes et les paires clé / valeur aux arguments, vous pouvez écrire une fois la plomberie d'un tel service Web, puis l'utiliser sur n'importe quelle classe de votre choix.

— tdammers
source

La réflexion est encore beaucoup plus lente que les appels directs. Deux choses ont changé:

Les temps d'exécution ont des mécanismes de réflexion optimisés de sorte que la différence est devenue plus petite
Les processeurs sont devenus plus rapides, de sorte que les petites inefficacités sont plus faciles à tolérer

Ensemble, ces deux facteurs ont réduit le coût de la réflexion au point où vous pouvez l'utiliser régulièrement (le cas échéant à partir d'un PDV de maintenabilité) et attendre que le profileur vous dise s'il s'agit réellement d'un goulot d'étranglement (et soyez raisonnablement sûr que la plupart des le temps qu'il ne sera pas).

— Michael Borgwardt
source

hélas, les processeurs sont devenus plus lents - généralement sur les appareils mobiles, et sur le serveur où les gens essaient de retirer le plus d'efficacité possible de leurs serveurs en raison des coûts de leur fonctionnement.

— gbjbaanb

@gbjbaanb: Je vais vous donner des appareils mobiles, mais sur le serveur, acheter plus de matériel plutôt que d'optimiser le code est le choix accepté et rationnel dans la grande majorité des cas, car les coûts d'achat et de fonctionnement des serveurs sont bien inférieurs à les coûts d'optimisation du code.

— Michael Borgwardt

Dans certaines situations, les coûts du serveur dépassent considérablement les coûts de développement. Dans un style à grande échelle. Même si les serveurs sont buff, les performances peuvent être encore plus critiques que sur une machine client. C'est un scénario au cas par cas.

— Lord Tydus

@ Lord Tydus: bien sûr, mais le cas que vous décrivez est la rare exception.

— Michael Borgwardt