Performances

Le proxy dynamique ajoute deux types de coût, tous deux faibles :

• Un coût unique par site d’appel passant par proxy. La première fois qu’un membre est appelé par proxy, le résolveur injecté résout la cible et raccorde le délégué. Cette opération est différée (elle ne concerne que les sites d’appel réellement atteints) et n’a lieu qu’une fois par site d’appel. Dans les applications qui font passer par proxy un très grand nombre d’appels distincts, elle peut ajouter un délai faible mais mesurable au démarrage ou à la première utilisation.
• Un coût négligeable en régime établi. Après le premier appel, les appels passent par le délégué mis en cache. Le surcoût par appel est de l’ordre de quelques nanosecondes et sans importance pour la grande majorité du code.

Comme le corps de la méthode appelée reste inchangé, les méthodes qui effectuent un vrai travail ne sont pas affectées en pratique. Le surcoût ne devient perceptible que pour des méthodes extrêmement petites appelées dans des boucles très sollicitées (des millions d’appels). Dans ces cas, et pour préserver un démarrage rapide lorsque seule une partie du code est sensible, utilisez les filtres pour ne faire passer par proxy que les appels qui ont besoin de protection, plutôt que l’assembly entier.

Notez que, si la protection par proxy dynamique apporte une couche d’obfuscation supplémentaire, elle peut avoir un léger effet sur le temps de démarrage de votre application, en raison de la génération et de l’initialisation des classes proxy. Le compromis entre une sécurité renforcée et un faible effet sur les performances est toutefois généralement jugé avantageux dans la plupart des cas.