Nous avions une discussion au bureau sur la manière de résoudre un problème particulier et d'utiliser un événement a été soulevé (pas de jeu de mots). La réponse était négative citera une mauvaise utilisation et qu'ils peuvent être coûteux.
Je comprends les préoccupations derrière toute utilisation abusive et je sais qu'elles ne sont qu'un délégué de multidiffusion spécial, mais donné un scénario où il y a au plus un auditeur, pourquoi utiliserait un événement sur un appel de méthode être considéré comme "cher"?
Juste pour être clair Cela ne concerne aucune implémentation particulière, il s'agit d'une question plus générale sur le coût de l'utilisation d'un événement sur un appel de méthode.
3 Réponses :
in .NET 2.0 appeler un délégué est tout aussi rapide en tant que Appel de méthode d'interface. Ils semblent même être un peu plus vite.
Mais même si les frais généraux étaient 10x plus élevés, je doute que les appels de délégués seraient jamais le goulot d'étranglement de la vitesse de votre application. Utilisez un profileur si vous voulez trouver les véritables goulots d'étranglement.
modifier en réponse à l'affirmation selon laquelle les événements sont plus lents que les délégués: en fait, les événements sont délégués. Ce code montre que leurs performances sont identiques, du moins sur ma machine.
Il n'y a pas d'application spécifique en tant que telle. La discussion où plus de rhétorique que toute autre chose, mais votre lien était très utile, merci.
Malheureusement, le lien que vous avez fourni utilisait des délégués et non des événements. Après avoir modifié le code, j'ai reçu des résultats similaires à Philip.
Votre lien est toujours utile pour que toute personne souhaite voir la comparaison en utilisant des délégués.
@Bronumski: événements sont délégués. Déclarer un événement est presque identique à la déclaration d'un domaine délégué. Voir ici pour les différences introduites à l'aide de l'événement Mot-clé: blog.monstuff. com / archives / 000040.html
@WIM: J'apprécie que les événements sont des délégués de multidiffusion avec la signature (objet, eventargs). Utilisation du code dans votre lien J'ai ajouté un test supplémentaire à l'aide d'un événement et les résultats ont été deux fois plus lents. Cela aurait pu être accéléré à l'aide de l'eventargS.empty statique plutôt que de créer un nouveau événement pour chaque appel, mais cela n'aurait pas été modélisé comment l'événement aurait été utilisé.
@Bronumski: Je suis lié à un code de test qui montre que la performance des événements et des délégués est identique.
Je suis d'accord avec ce que vous disent que vous dites que appeler un délégué avec la même signature qu'un événement (objet O, evenargs e) est exactement le même. Mon point est que si vous souhaitez appeler une méthode sans paramétrage, que ce soit directement ou via un délégué, vous n'allez pas imposer la signature ci-dessus sur cette méthode si vous n'êtes pas obligé. Comme sage si vous souhaitez transmettre la méthode un paramètre, vous n'allez pas nécessairement envelopper cet objet dans un autre objet (Eventargs). Encore une fois, votre comparaison directe est correcte mais être pratique, vous devez accepter les frais généraux de la création d'un objet Eventarg si vous souhaitez utiliser des événements.
@BRONUMSKI: Vous pouvez déclarer des événements comme un system.action (E.g. Action d'événement public
Point équitable, quelque chose que je n'avais même pas envisagé, j'utilisais le générique EventHandler. Il montre que l'événement est un peu plus lent mais pas aux extrêmes que je regardais. Merci de me montrer ça.
C'était intéressant. J'ai changé d'ihandler, de gestionnaire et de religion à être public et j'ai obtenu de meilleurs résultats: avant le délégué = 0,0960055, événement = .1200068, interface = .1100063 Après délégué = .1240071, interface = .1100062, interface = .1100062 Les résultats pour le l'interface et l'événement ont été inversés.
@WIM j'ai posté mon code dans ma réponse - Je tiens à noter que avec nos deux codes, je reçois des résultats assez différents (pas seulement le temps supplémentaire, mais des coûts relatifs!) Par le biais de débogage / de libération ou de débogueur attaché / non joint.
La performance n'est définitivement pas quelque chose que vous devriez vous préoccuper. Vous parlez de nanosecondes ici. Si vous n'avez qu'un seul auditeur, il n'y a pas de différence du tout.
Je considérerais simplement ce qui a plus de sens dans votre application, en utilisant des événements ou appelez une méthode et choisissez la meilleure option. La principale différence étant qu'un objet A générant des événements n'a pas à connaître son (s) auditeur (s). Le même objet A appeler une méthode doit connaître l'instance pour l'appeler. Où voulez-vous mettre la dépendance?
Je suis d'accord avec votre déclaration et tout le but de la discussion était de convenir d'un schéma logique et clair. Ma question ici n'était que pour obtenir une clarté sur la déclaration selon laquelle "les événements sont chers".
Strictement parlant, l'abonnement aux événements oblige l'éditeur à capturer une instance de l'abonné - c'est une chose importante à comprendre. Dans une perspective de conception, vous êtes correct, mais utiliser une interface découplerait suffisamment vos objets.
Testez-le dans votre scénario - j'imagine que beaucoup, de nombreux facteurs peuvent affecter cela, surtout lorsque nous parlons quelque chose avec un coût relatif aussi faible en tant que méthode / appel de délégué.
Un test rapide et simple avec Une version de libération non sous un débogueur, compilée sous 4,0 en tant que "Toute processeur" et fonctionnant sur Windows 7: P>
autre édition forte>: Oups Voici un meilleur résultat. Voir Le code pour comment cela fonctionne p> 10000000 direct reference calls : 0.011 s
10000000 calls through an interface : 0.037 s
10000000 invocations of an event : 0.067 s
10000000 calls through Action<int> : 0.035 s
La question n'était pas à propos de quelque conception notamment de la raison pour laquelle "les événements seraient considérés comme coûteux". Il n'y a pas de scénario de test particulier, mais merci de faire votre test et de partager les résultats, il répond à la question et devrait être utile pour les autres.
Certains événements peuvent être plus chers que d'autres - comme certains appels de méthode peuvent être plus chers. En particulier, des événements qui effectuent une commodité marshaling (ou géré par COM) se viennent à l'esprit. Bien que cela nuit au point principal ("sont des délégués à plusieurs cases chers?"), Je pense que cela peut s'intégrer avec la conception (MIS) des événements "coûteux".