Can Stopwatch be used in production code?

Question

I need an accurate timer, and DateTime.Now seems not accurate enough. From the descriptions I read, System.Diagnostics.Stopwatch seems to be exactly what I want.

But I have a phobia. I'm nervous about using anything from System.Diagnostics in actual production code. (I use it extensively for debugging with Asserts and PrintLns etc, but never yet for production stuff.) I'm not merely trying to use a timer to benchmark my functions - my app needs an actual timer. I've read on another forum that System.Diagnostics.StopWatch is only for benchmarking, and shouldn't be used in retail code, though there was no reason given. Is this correct, or am I (and whoever posted that advice) being too closed minded about System.Diagnostics? ie, is it ok to use System.Diagnostics.Stopwatch in production code? Thanks Adrian

Estelleesten

What type of timer do you need? Do you want some method to be invoked after some time has elapsed, or do you need to know how much time has elapsed until now? What precision do you need? – Comedown

possible duplicate of how to get a real time clock in C#?. I don't see how this differs from the other question. Maybe if you change it to, "is there any problem using System.Diagnostics classes in production, but now it's a duplicate". – Ressler

@John - IMO, definitely not a duplicate. The other question asks how to do it; this question asks if it's OK to do it. The other OP may have some weird reason for avoiding Stopwatch (e.g. insane corporate BS rules that make no sense yet still must be followed.. No, I'm not bitter!) – Shizukoshizuoka

I felt the same way about using anything from System.Diagnostics namespace. After checking credible sources, like MSDN, it is much more desirable to use Stopwatch. I have even implemented my own because I needed events: msdn.microsoft.com/en-us/library/aa457094.aspx – Particulate

Answer 1

Under the hood, pretty much all Stopwatch does is wrap QueryPerformanceCounter. As I understand it, Stopwatch is there to provide access to the high-resolution timer - if you need this resolution in production code I don't see anything wrong with using it.

Morphophoneme

We use QueryPerformanceCounter all the time in production code. It is perfectly reasonable to use this infrastructure in prod. – Simonson

Answer 2

Yes, System.Diagnostics does sound like it is for debugging only, but don't let the name deceive you. The System.Diagnostics namespace may seem a bit scary sounding for use in production code at first (it did for me), but there are plenty of useful things in that namespace.

Some things, such as the Process class, are useful for interacting with the system. With Process.Start you can start other applications, launch a website for the user, open a file or folder, etc.

Others things, such as the Trace class, can help you track down bugs in production code. Granted, you will not always use them in production code, but they are very useful for logging and tracking down that elusive bug on a remote machine.

Don't worry about the name.

Ardor

Answer 3

You say you've read on another forum not to use classes from System.Diagnostics in production. But the only source you should worry about is Microsoft, who created the code. They say that the StopWatch class:

Provides a set of methods and properties that you can use to accurately measure elapsed time.

They don't say, "except in production".

Ressler

Answer 4

Afaik StopWatch is a shell over QueryPerformanceCounter functionality. This function is the basis of a lot of performance counters related measurements. QPF is very fast to call and perfectly safe. IF you feel paranoid about the Diagnostics namespace, pInvoke the QPF directly.

Suasion

"IF you feel paranoid about the Diagnostics namespace, pInvoke the QPF directly.": bad advice, considering how nicely Stopwatch hides the complexity of the native API and P/Invoking into it. Should really be: "Don't feel paranoid about Stopwatch just because it's in the System.Diagnostics namespace". – Gasman

Answer 5

The stopwatch is basically a neat wrapper around the native QueryPerformanceCounter and QueryPerformanceFrequency methods. If you don't feel comfortable using the System.Diagnostic namespace, you can access these directly.

Using the Performance Counter is very common, there is nothing wrong with that. AFAIK, there is no higher timer precision available. Note the QPF might lead to problems with multi processor machines, but the MSDN Article linked before gives some additional information on that. It is advisable to make sure System.Diagnostics.Stopwatch does that in the background or to call the SetThreadAffinity manually - otherwise your timer might jump back in time!

Note that for very high precision measurements, there are some subtleties that need to be taken into account. If you need this much precision, these might be of some concern.

Comedown

Answer 6

There are several different timer classes in the .NET base class library - which one is best suited to your needs can only be determined by you.

Here is a good article from MSDN magazine on the subject (Comparing the Timer Classes in the .NET Framework Class Library).

Cispadane

Answer 7

Depending on what you're using the timer for, you may have other issues to consider. Windows does not provide guarantees on timing of execution, so you shouldn't rely on it for any real-time processing (there are real-time extensions you can get for Windows that provide hard real-time scheduling). I also suspect you could lose precision as a result of context switching after you capture the time interval and before you do something with it that depends on its precision. In principle, this could be an arbitrarily long period of time; in practice it should be on the order of milliseconds. It really depends on how mission-critical this timing is.

Ameeameer