CODEWITHSUNDEEP
.netwindowshardware-interfacestopwatch
Soundar Rajan
Soundar Rajan

Reputation: 517

.NET Stopwatch Class limitations

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?

Upvotes: 2

Views: 1885

Answers (6)

HypnoToad
HypnoToad

Reputation: 605

The stopwatch class is pretty simple. It's not something that "runs" all the time. When you tell it to start, it looks at the system time, and when you tell it to pause, stop, reset, etc is just looks at the system time each time you do this. Asking the ElapsedMilliseconds is equivalent to saying (Processor.CurrentTicks - StartTicks) / TicksPerMillisecond. It's pretty simple, really. The system can handle a very large number of these.

I'm not commenting on whether or not this is the right design for your problem, just answering your question: the system can handle thousands of stopwatches with no problem.

Upvotes: 0

Steven A. Lowe
Steven A. Lowe

Reputation: 61242

use one time source to schedule events at specified intervals

Upvotes: 0

devdimi
devdimi

Reputation: 2462

Think of global queue which holds gadgets responses and one or a few threads that query the queue and resents messages if needed. It would perform better.

Upvotes: 0

Daniel Brückner
Daniel Brückner

Reputation: 59705

I think the question should be if you can handle some many timers; you will waste much time just reading thousands of timers and doing no functionality.

I am not aware of the implementation behind the Stopwatch class, but I can imagine that they just read the value of a timer on start and on stop again. So a Stopwatch instance might need allmost no resources.

But just try it out; generate an array of some thousend instances in a loop, start them, and look what happens.

Upvotes: 0

Anton Tykhyy
Anton Tykhyy

Reputation: 20086

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.

Upvotes: 7

Reed Copsey
Reed Copsey

Reputation: 564851

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.

Upvotes: 8

Related Questions