Is the System.Diagnostics.Stopwatch class normally slow when called repeatedly?

Question

I have an application which must transmit packets at fixed intervals of 33ms +/- a few milliseconds.

So, I came up with a SpinTimer class shown below:

class SpinTimer
{
    public void SpinWait(double waitTimeInSeconds)
    {
        if (waitTimeInSeconds < 0.0)
        {
            throw new ArgumentOutOfRangeException("waitTimeInSeconds", "Must be >= 0.0");
        }

        Stopwatch timer = new Stopwatch();
        double elapsed = 0.0;
        timer.Start();
        do
        {
            elapsed = (double)timer.ElapsedTicks / (double)Stopwatch.Frequency;
        } while (elapsed < waitTimeInSeconds);
    }
}

However, after profiling the code, I found that the System.Diagnostics.Stopwatch.GetTimestamp() call was taking most of the execution time. Just as a note, I can't afford to have the thread sleep and context switch as this causes too much "jitter" in the output rate.

Notes about the profile run:

Thread priority was set to ThreadPriority.Highest
Process priority was set to ProcessPriorityClass.High

The original program that I wrote (in C++) accomplished the same effect using the QueryPerformanceCounter() and QueryPerformanceFrequency() functions. Should I be using these calls with PInvoke instead of the Stopwatch class? Or, is there another appropriate way to do this?

Thanks!

I am confused by the question. You are sitting there in a *tight loop* doing nothing but querying the current time. It should not be a surprise that your performance tests show that you're spending most of your execution time querying the current time! — Eric Lippert, Feb 16 '12 at 20:53
I wasn't surprised by it taking time, but how much time... The equivalent C++ code accurately waits (within the frequency spec) the required amount of time. Whereas, the C# code is extremely slow when `SpinWait` is executed vs. not. — mevatron, Feb 16 '12 at 21:05
Also see http://stackoverflow.com/questions/795377/what-if-any-is-the-resource-penalty-for-using-system-diagnostics-stopwatch — nawfal, Apr 22 '13 at 12:24

score 2 · Answer 1 · answered Feb 16 '12 at 20:53

2

The stopwatch is in the diagnostics namespace. It shouldn't be used for performance level timing.

you probably want a Timer.

answered Feb 16 '12 at 20:53

McKay

12,334
7
53
76

score 2 · Answer 2 · answered Feb 16 '12 at 20:55

2

have you tried using a System.Windows.Threading.DispatcherTimer ?

I've created several programs with this, and never experienced any delay at all

answered Feb 16 '12 at 20:55

mevatron · Accepted Answer · 2012-02-21T16:14:05.913

After, some more debugging (inspired by Eric Lippert's comment), I realized that my above code was doing exactly as requested. The problem was with the calling code at a higher level of abstraction feeding it extremely long wait times.

Thanks for the suggestions to use System.Windows.Threading.DispatcherTimer and System.Timers.Timer (I gave both an up-vote); however, after testing each of these, they are limited to ~10 milliseconds of accuracy, which is just not quite good enough for my purposes. But, I did find that my "tight" loop code above is accurate to ~1 microsecond, which is more than enough for my current needs.

An additional resource that others might find helpful is this CodeProject article about increasing the Stopwatch accuracy. The main idea is to essentially reduce the likelihood that your program will endure a context switch, and thus travel through the scheduling queues wasting time.

Is the System.Diagnostics.Stopwatch class normally slow when called repeatedly?

3 Answers3