Utilisation élevée du processeur Lorsque vous utilisez ErrorProvider dans WinForms, pourquoi?

Question

J'ai une application qui va dans une utilisation élevée du processeur (lentement dans le temps) lorsque le contrôle ErrorProvider définit l'icône clignotante en continu sur plusieurs commandes.

L'utilisation élevée du processeur n'est pas immédiate mais a une rampe lente jusqu'à ce que l'application atteigne 100% de processeur.

Lorsqu'il n'y a pas d'erreur affichée, le processeur remonte à la normale. Est-il normal que l'erreurprovider prenne autant de temps de processeur?

Answer 1

Selon ce rapport de bogue MS Connect: Les ressources graphiques fuisent dans ErrorProvider

Lorsqu'il y a une erreur associée à un contrôle, le composant ErrorProvider affiche une icône clignotante à sa droite. J'ai découvert que chaque fois que l'icône clignote, un nouveau DeviceContext est ajouté à la liste interne System.Drawing.internal.DeviceContexts. Et lorsque j'appelle la méthode Dispose () sur l'objet ErrorProvider, la liste DeviceContexts n'est pas effacée.

Conséquence: par défaut, l'icône clignote tous les 250 ms, donc 4 objets DeviceContext sont ajoutés à la liste System.Drawing.internal.DeviceContexts par seconde. Lorsqu'un ErrorProvider est actif et que le blinkstyle est toujoursBlink, la liste se développe indéfiniment ... et lorsque cette liste est très grande (je l'ai vue avec 500000+ objets!) Les opérations de dessin d'application sont très très très lentes :(

Ce bogue est marqué comme fixe mais le commentaire le plus récent indique qu'il fait l'objet d'une enquête.

Answer 2

Ce n'est pas normal. Selon toute vraisemblance, vous fuyez des poignées de mémoire ou de fenêtres. Commencez à diagnostiquer cela avec TaskMgr.exe, Onglet Processus. Affichage + Sélectionnez les colonnes et la mémoire de cochez (Taille de validation), les poignées, les objets utilisateur et les objets GDI. Observez les valeurs de ces colonnes pendant que votre application s'exécute.

L'augmentation régulière des valeurs indique un problème dans votre code qui peut faire monter l'utilisation du processeur. Un problème assez classique consiste à fuir des poignées d'utilisateurs, induites en supprimant les commandes de votre formulaire avec des contrôles.Remove () ou des contrôles.Clear () et en oubliant de disposer de ces contrôles.