A little late on this, I know, but . . .
System.Timers.Timer
is a wrapper around System.Threading.Timer
, which in turn is a .NET wrapper around Windows' Timer Queues. Timer queue timers are very lightweight--use few system resources. I've not scaled to thousands of timers, but hundreds of timers works just fine. From what little I've been able to glean of the implementation, I can't imagine that there would be any trouble with thousands of timers.
There's probably some limit on the number of timers you can have in any particular timer queue. I don't know what that limit is. When I investigated these timers a year or so ago, it looked like the .NET Framework creates one timer queue per process (or maybe it was per app domain), and all the timers you create are put into that one queue.
It probably doesn't make sense to duplicate the timer queue functionality by creating your own system that uses a single timer and some type of priority queue mechanism to control what's called next. That's what the timer queue does for you already.
It seems like you could easily build a test program that creates 10,000 timers. Set each one to tick one second after the last, and set its period to 10,000 seconds. Then sit back and watch it tick. Or have your program keep track of who should tick next and who actually ticks next.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…