.NET Stoppuhr-Klasseneinschränkungen

Question

Dies ist möglicherweise keine vollständig keine .NET-verwandte Frage. Ich schreibe eine .NET-Anwendung, um einige Gadgets zu steuern. Ich sende regelmäßig Befehle an das Gadget (etwa alle 500 Millisekunden). Sobald ich den Befehl sende, starte ich einen Timer. (.NET-Stoppuhrklasse)

Wenn das Gadget nicht innerhalb von sagen wir 10 Millisekunden reagiert, sende ich den Befehl erneut. Wenn dies der Fall ist, überwache ich den Gadget-Status, indem ich weitere Befehle sende und die Antworten verarbeite.

Ich habe 2 oder 3 Stoppuhr-Timer parallel laufen, um andere Dinge für dieses eine Gadget zu tun.

Jetzt möchte ich potenziell Tausende dieser Gadgets überwachen und steuern (könnte so hoch wie 5000 sein). Wenn ich ein Objekt für ein Gadget erstelle, suche ich nach 10000 bis 15000 Stoppuhr-Objekten, die parallel laufen. Ich bin nicht sicher, wie die Stoppuhren funktionieren, aber ich nehme an, dass sie sich auf einen Hardware-Timer oder etwas ähnliches verlassen, um die Zeit zu verfolgen.

Meine Frage ist, können Fenster so viele Stoppuhren gleichzeitig behandeln?

Answer 1

Ich würde empfehlen, dieses Design zu überdenken. Zunächst einmal macht Stopwatch genau das, was es sagt - es verhält sich wie eine Stoppuhr. Wenn Sie möchten, dass ein Ereignis in bestimmten Intervallen ausgelöst wird, sollten Sie sich die verschiedenen Timer-Klassen ansehen.

Das heißt, ich würde empfehlen, Ihre Timer über die Gadgets zu teilen. Sie werden feststellen, dass alles viel besser läuft, und es ist wahrscheinlich einfacher zu schreiben und zu verstehen, wenn Sie weniger Timer haben, die von einem einzelnen Scheduler verwendet werden, den Sie erstellen, und der Scheduler verwaltet die Gadgets.

Answer 2

Eine Stoppuhr ist nichts anderes als eine Variable, die das Ergebnis des Windows-API-Aufrufs QueryPerformanceCounter() enthält. Sie hat keinen Overhead, während sie "läuft". Stoppen Sie es noch einmal QueryPerformanceCounter(), so sollte die Leistung in Ordnung sein. Das stimmt, ich stimme mit Reed Copsey überein, du musst dein Design überdenken. Bei so vielen Gadgets würde ich über einen Gerätetreiber nachdenken.

Answer 3

Ich denke, die Frage sollte sein, wenn Sie einige viele Timer behandeln können; Sie werden viel Zeit verschwenden, wenn Sie nur Tausende von Timern lesen und keine Funktionen ausführen.

Ich bin mir nicht bewusst über die Implementierung hinter der Stoppuhr-Klasse, aber ich kann mir vorstellen, dass sie nur den Wert eines Timers beim Start und beim Stopp wieder lesen. Daher benötigt eine Stoppuhr-Instanz möglicherweise fast keine Ressourcen.

Aber probieren Sie es einfach aus; erzeuge ein Array von einigen tausend Instanzen in einer Schleife, starte sie und schau was passiert.

Answer 4

Denken Sie an die globale Warteschlange, die Gadgets-Antworten und einen oder wenige Threads enthält, die die Warteschlange abfragen und bei Bedarf Nachrichten zurückweisen. Es würde besser funktionieren.

Answer 5

Verwendung einer Zeitquelle Ereignisse in bestimmten Intervallen

Answer 6

Die Stoppuhr-Klasse ist ziemlich einfach zu planen. Es ist nicht etwas, das die ganze Zeit "läuft". Wenn Sie sagen, dass es zu starten ist, sieht es auf die Systemzeit, und wenn Sie sagen, dass es zu pausieren, stoppen, zurücksetzen, etc ist nur jedes Mal, wenn Sie dies tun, die Systemzeit betrachtet. Das Abrufen der ElapsedMilliseconds entspricht dem Aussprechen (Processor.CurrentTicks - StartTicks)/TicksPerMillisecond. Es ist ziemlich einfach. Das System kann eine sehr große Anzahl von diesen verarbeiten.

Ich kommentieren nicht, ob dies das richtige Design für Ihr Problem ist, nur Ihre Frage zu beantworten: Das System kann Tausende von Stoppuhren ohne Problem behandeln.