We have an application containing a lot of user controls that update frequently based on a System.Windows.Forms.Timer. Am I safe to add a Timer instance to each control peformancewise? Or should I have one Singleton Timer that runs all the time that is to be used by all instances? What is acutally happening under the hood? Will there be a an additional thread (for counting) for each timer?
System.Windows.Forms.Timer
is implemented via good ol' User32 Timers. As such, they do not use or require a separate thread for operation. That said, they are a limited resource, in that you cannot have an infinite number of them.
When you say you have a lot of user controls using timers, what do you really mean by "a lot"? 10? 10000?
When you say they update frequently, what do you really mean? Every minute? Every 100 milliseconds? As fast as their timers can fire?
Stress test your app. See how many controls you can have active before it starts crashing or becomes so slow as to be unusable. Chances are, you'll hit the point where the overhead of internal processing for WM_TIMER
messages kills performance long before you run out of other resources.
There is no additional thread. There are just a lot of WM_TIMER messages coming in your thread's message queue. So these timers won't execute their code in parallel, even if their timespans overlap.
I think that it wouldn't hurt to have a separate timer for evey control. At least it definately won't have any measureable performance difference over using a single timer. The code will get more readable though. ;)
Btw - with todays massive move to multiple CPU cores, consider if this perhaps isn't a place where you can benefit from it.
Do the timers fire at different times for each control? Do they each need a seperate timer?
Remember you can hook up several event handlers to a single event, so if you're using the timers to do some simple animation, you could perhaps do that with one timer firing events for many controls...