Pourquoi l'événement Winforms Click est-il plus lent que l'événement MouseClick?

Question

J'ajoute des boutons pour former avec une boucle et j'ai remarqué que l'ajout de gestionnaires d'événements click ralentissait trop l'application. Plus tard, j'ai essayé l'événement de clic de souris à la place cliquez sur l'événement et il fonctionne instantanément.

Cette capture d'écran montrant le résultat de mon test: code source: http://pastebin.com/qVewNm1u

Résultats pour gestionnaire d'événements 1000:
Clics: 2892ms MouseClick: 1ms

Je ne peux pas comprendre pourquoi Cliquez sur l'événement très lent.

Edit: Si je change construire la cible de plate-forme pour x64 ou Any CPU, les résultats changer: Clics: 5, MouseClick: 9 Regardez comme objectif de la plate-forme x86 l'origine de ce problème, mais encore des résultats x64 pas de bons trop par rapport à x86 MouseClick temps (1ms).

Edit2: J'ai changé de capture d'écran maintenant il va montrer un meilleur résultat.

Edit3: https://connect.microsoft.com/VisualStudio/feedback/details/597039/winforms-click-event-slower-than-the-mouseclick-event

Answer 1

Je repro, mais il est spécifique à VS2010. Il n'y a pas de tel comportement dans VS2008, les deux s'exécutent en moins de 1 tick. Cela ne dépend pas non plus de la version .NET.

Cela ressemble à un défaut dans IntelliTrace, disponible dans l'édition Ultimate. Essayer de creuser plus profond et de tourner le débogage de code non managé sur enlevé l'effet. Projet + Propriétés, onglet Déboguer, cochez "Activer le débogage de code non géré".En outre, l'exécution du programme sans le débogueur (Ctrl + F5) a supprimé l'effet. Le slam-dunk est Outils + Options, IntelliTrace, Général, décocher Activer pour supprimer l'effet.

Je vous recommande d'envoyer vos résultats à connect.microsoft.com. Vous pouvez référencer ce fil dans votre rapport de commentaires. Tout ce qu'ils doivent savoir pour diagnostiquer le problème est disponible.

Comme indiqué, la solution de contournement consiste à désactiver IntelliTrace. Ceci est garanti pour ne pas être un problème sur la machine de votre client.

Answer 2

Avez-vous essayé de créer les boutons d'abord, avant de mesurer l'attachement du gestionnaire d'événements?

Il y a au moins deux inconnues ici: 1) l'heure d'exécution du constructeur du bouton, et 2) l'abonnement au gestionnaire d'événements.

Mise à jour: J'ai essayé de reproduire le problème mais j'ai toujours 4ms-6ms pour les deux tests. Le test est-il toujours plus lent, ou est-ce arrivé une seule fois? Parfois, des choses étranges se produisent avec jitting et GCing qui ne sont pas toujours déterministes à 100%.

Answer 3

Bien que je ne puisse pas vous dire ce qui se passe, il existe un certain nombre de problèmes avec votre suite de tests. Tout d'abord, vous devriez probablement arrêter la minuterie avant de faire la Console.WriteLine, puisque vous mesurez maintenant combien de temps il faut pour créer la chaîne utilisée dans WriteLine. Deuxièmement, vous pouvez créer les boutons avant de démarrer le minuteur, car vous mesurez également le temps de création du bouton, qui inclut la pile, le tas, la récupération de place et d'autres problèmes potentiels. Je suggère d'allouer les boutons à un tableau, puis d'affecter les gestionnaires pairs aux éléments après le démarrage du chronomètre.

Answer 4

Je ne suis pas sûr car je n'ai qu'un petit 4ms pour ClickTest(). Cependant, j'ai changé le code pour cela et le temps 4ms est parti.

EventHandler d = new EventHandler(Form1_Click); 
for (int i = 0; i < buttons.Length; i++) buttons[i].Click += d; 

Le code dans la boucle que vous avez écrit équivalent à button[i].Click += new EventHander(Form_Click), qui créent nouvelle instance de délégué à chaque itération.