Take the 2-minute tour ×

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;
            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:

  1. Thread priority was set to ThreadPriority.Highest
  2. 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?


share|improve this question
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 stackoverflow.com/questions/795377/… –  nawfal Apr 22 '13 at 12:24
add comment

3 Answers

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

you probably want a Timer.

share|improve this answer
add comment

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

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

share|improve this answer
add comment
up vote 1 down vote accepted

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.

share|improve this answer
add comment

Your Answer


