Kann Stoppuhr im Produktionscode verwendet werden?

Ich brauche einen genauen Timer und DateTime.Now scheint nicht genau genug zu sein. Aus den Beschreibungen, die ich gelesen habe, geht hervor, dass System.Diagnostics.Stopwatch genau das ist, was ich will.

Aber ich habe eine Phobie. Ich bin nervös, irgendetwas von System.Diagnostics im tatsächlichen Produktionscode zu verwenden. (Ich verwende es ausgiebig zum Debuggen mit Asserts und PrintLns usw., aber noch nie für Produktionszwecke.) Ich versuche nicht nur, einen Timer zum Benchmarking meiner Funktionen zu verwenden - meine App benötigt einen tatsächlichen Timer. Ich habe in einem anderen Forum gelesen, dass System.Diagnostics.StopWatch nur zum Benchmarking dient und nicht im Einzelhandelscode verwendet werden sollte, obwohl kein Grund angegeben wurde. Ist das richtig oder bin ich (und wer auch immer diesen Rat gepostet hat) zu verschlossen gegenüber System.Diagnostics? Ist es in Ordnung, System.Diagnostics.Stopwatch im Produktionscode zu verwenden? Danke Adrian

Unter der Haube ist so ziemlich alles, was Stopwatch tut, QueryPerformanceCounter zu verpacken . Soweit ich weiß, ist Stoppuhr dazu da, den Zugriff auf den hochauflösenden Timer zu ermöglichen. Wenn Sie diese Auflösung im Produktionscode benötigen, sehe ich nichts Falsches daran, sie zu verwenden.

Ja, System.Diagnosticshört sich so an, als wäre es nur zum Debuggen gedacht, aber lassen Sie sich nicht vom Namen täuschen. Der System.DiagnosticsNamespace mag auf den ersten Blick etwas beängstigend klingen, wenn er im Produktionscode verwendet wird (das war für mich der Fall), aber dieser Namespace enthält viele nützliche Dinge.

Einige Dinge, wie die ProcessKlasse, sind nützlich für die Interaktion mit dem System. Mit können Process.StartSie andere Anwendungen starten, eine Website für den Benutzer starten, eine Datei oder einen Ordner öffnen usw.

Andere Dinge, wie die TraceKlasse, können Ihnen helfen, Fehler im Produktionscode aufzuspüren. Zugegeben, Sie werden sie nicht immer im Produktionscode verwenden, aber sie sind sehr nützlich, um diesen schwer fassbaren Fehler auf einem Remotecomputer zu protokollieren und aufzuspüren.

Mach dir keine Sorgen über den Namen.

Sie sagen, Sie haben in einem anderen Forum gelesen, dass Sie keine Klassen aus der System.DiagnosticsProduktion verwenden sollen. Die einzige Quelle, über die Sie sich Sorgen machen sollten, ist Microsoft, das den Code erstellt hat. Sie sagen, dass die StopWatchKlasse :

Bietet eine Reihe von Methoden und Eigenschaften, mit denen Sie die verstrichene Zeit genau messen können.

Sie sagen nicht "außer in der Produktion".

Afaik StopWatch ist eine Shell über die QueryPerformanceCounter- Funktionalität. Diese Funktion ist die Grundlage vieler Messungen im Zusammenhang mit Leistungsindikatoren. QPF ist sehr schnell anzurufen und absolut sicher. Wenn Sie sich in Bezug auf den Diagnose-Namespace paranoid fühlen, rufen Sie den QPF direkt auf.

Die Stoppuhr ist im Grunde eine ordentliche Hülle um das Native QueryPerformanceCounterund die QueryPerformanceFrequencyMethoden. Wenn Sie sich mit dem System.DiagnosticNamespace nicht wohl fühlen , können Sie direkt darauf zugreifen .

Die Verwendung des Leistungsindikators ist sehr verbreitet, daran ist nichts auszusetzen. AFAIK, es gibt keine höhere Timer-Präzision. Beachten Sie, dass der QPF zu Problemen mit Multiprozessor-Computern führen kann. Der zuvor verlinkte MSDN-Artikel enthält jedoch einige zusätzliche Informationen dazu. Es ist ratsam, System.Diagnostics.Stopwatchdies im Hintergrund sicherzustellen oder SetThreadAffinitymanuell aufzurufen - andernfalls könnte Ihr Timer in der Zeit zurückspringen !

Beachten Sie, dass bei Messungen mit sehr hoher Präzision einige Feinheiten berücksichtigt werden müssen. Wenn Sie so viel Präzision benötigen, können diese von Belang sein.

In der .NET-Basisklassenbibliothek gibt es mehrere verschiedene Timer-Klassen. Welche für Ihre Anforderungen am besten geeignet ist, kann nur von Ihnen bestimmt werden.

Hier ist ein guter Artikel aus dem MSDN-Magazin zu diesem Thema (Vergleichen der Timer-Klassen in der .NET Framework-Klassenbibliothek).

Je nachdem, wofür Sie den Timer verwenden, müssen Sie möglicherweise andere Probleme berücksichtigen. Windows bietet keine Garantie für den Zeitpunkt der Ausführung, daher sollten Sie sich bei der Echtzeitverarbeitung nicht darauf verlassen (es gibt Echtzeiterweiterungen für Windows, die eine harte Echtzeitplanung ermöglichen). Ich vermute auch, dass Sie aufgrund von Kontextwechseln an Genauigkeit verlieren könnten, nachdem Sie das Zeitintervall erfasst haben und bevor Sie etwas damit tun, das von seiner Genauigkeit abhängt. Im Prinzip kann dies ein beliebig langer Zeitraum sein; in der Praxis sollte es in der Größenordnung von Millisekunden liegen. Es hängt wirklich davon ab, wie geschäftskritisch dieses Timing ist.