Surcharge du temporisateur dans l'application C#

Combien de temps les minuteurs génèrent-ils dans une application s'ils s'exécutent en arrière-plan en continu (quel que soit l'intervalle)? Je ne m'inquiète pas des appels que la minuterie fera quand elle se déclenche, mais plutôt des effets de performance de l'utilisation des minuteurs dans les applications où la performance est de la plus haute importance et je suis curieux d'entendre ce que les vues sont sur ce .Surcharge du temporisateur dans l'application C#

Source

2010-10-14 Madeleine

Il y a-t-il des types d'heures dans .net http://msdn.microsoft.com/en-us/magazine/cc164015.aspx dont vous parlez? – Andrey

Eh bien, je parlais des minuteurs en général - mais l'application en cours où j'étais le plus concerné est une application Silverlight, donc j'utiliserais le DispatcherTimer. Merci – Madeleine

La minuterie, entre ses tics, ajoute un coût extrêmement faible à l'application. Il utilise le mécanisme du système d'exploitation pour la planification (qui est active quelles que soient vos actions), par opposition au concept intuitif d'interrogation constante de l'horloge du système. Fondamentalement, à part l'ajout de données additionnelles de mémoire et de changement de contexte (ajouts mineurs dans ce cas, il ne devrait pas y avoir plus qu'ajouter un bouton à votre formulaire) il ne devrait plus y avoir de surcharge.

Source

2010-10-14 12:42:25 Neowizard

Quand il s'agit de minuteries et de threads, "pooling" et "polling" sont deux mots différents que l'on devrait faire attention à épeler correctement;) – d7samurai

Oups! Ma faute. Merci, @ d7samurai. – Neowizard

Le "mécanisme d'ordonnancement du système d'exploitation" que vous mentionnez est appelé [** boucle de messages **] (https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows) qui met en file d'attente les messages. L'application a une boucle d'événement qui reçoit des messages de cette file d'attente de messages. – BornToCode

L'événement invoqué par le temporisateur s'exécutera dans le même thread auquel appartient le temporisateur et bloquera donc ce thread lors de l'exécution de toute logique. Cela signifie que si le temporisateur appartient à la couche GUI, l'exécution de la méthode Timer.Tick verrouillera l'interface graphique pendant son exécution.

Pour maintenir les performances dans le thread principal, je suggère d'utiliser un BackgroundWorker à la place qui fonctionne dans son propre thread.

Source

2010-10-14 12:34:30

Il ya il types de fois dans .net http://msdn.microsoft.com/en-us/magazine/cc164015.aspx dont vous parlez? – Andrey

Je faisais référence à System.Windows.Forms.Timer avec ma déclaration ci-dessus. –

Pour répondre de la même manière: les temporisateurs sont inestimables pour la programmation gui, mais sont pratiquement inutiles pour les tâches hautes performances. Quelques problèmes avec minuteries:

ils ne sont pas régulièrement à la milliseconde (en fait dans les fenêtres, rien est) - il se déclenche quand est son temps, mais quand tous les autres messages (événements-clavier de la souris, les mises à jour de contrôle) sont traitées, car il est sérialisé avec d'autres messages de/à
gui ne savent pas la mise en œuvre de .net, mais ils gaspillés poignées mfc

Si vous envisagez un autre thread pour une opération, assurez-vous que vous ne touchez aucun composant gui de celui-ci. Utilisez Invoke() ou copiez des mises à jour pour un gui dans une file d'attente, puis supprimez-le avec le timer du thread principal gui.

Source

2010-10-14 12:42:16

Surcharge du temporisateur dans l'application C#

Répondre

Questions connexes