.NET Stopwatch Class limitations

Question

This may not be an entirely not a .NET related question. I am writing a .NET application to control some gadgets. I send commands to the gadget periodically (say every 500 milliseconds). As soon as I send the command I start a timer. (.NET stopwatch class)

If the gadget not respond within say, 10 milliseconds, I send the command again. If it does respond, I continue to monitor the gadget status by sending more commands and processing the responses.

I have 2 or 3 stopwatch timers running in parallel to do other things for this one gadget.

Now, I want to monitor and control potentially thousands of these gadgets (could be as high as 5000). If I create one object for a gadget, I will looking at 10000 to 15000 stopwatch objects running in parallel. I am not sure how the stopwatches work but I assume they rely on a hardware timer or some such thing to keep track of time.

My question is, can windows handle such a large number of stopwatches simultaneously?

Answer 1

I would recommend rethinking this design. First off, Stopwatch just does what it says - it acts like a stopwatch. If you want an event to fire at specific intervals, you'll want to look at the various Timer classes.

That being said, I would recommend sharing your Timers across the gadgets. You will find that everything performs much better, and is probably simpler to write and comprehend if you have fewer timers which are used by a single scheduler you create, and the scheduler manages the gadgets.

Answer 2

A stopwatch is nothing but a variable holding the result of Windows API call QueryPerformanceCounter(), it has no overhead while it's "running". Stopping it calls QueryPerformanceCounter() once more, so performance should be okay. That said, I agree with Reed Copsey, you need to rethink your design. With such a large number of gadgets, I'd start thinking about a device driver.