I've been using some timers in an application I'm developing. However, I've been noticing some hiccups in the softwares performance. In an article I was reading on Timer, its stated I should not put too much code in a Timer event. How much is too much?
To be honest, Timers shouldn't be used at all, even though they are easy to use. They are slow, inconsistant, inaccurate, and if your app is used on Windows XP, they go 10 times faster than usual, making them REALLY inaccurate and inconsistant. And it gets worse the more timers you use.
Using managed loops is the way to go. I'll upload a project for you in 30 minutes.
I should not put too much code in a Timer event. How much is too much?
The code that is going to run the the Timer Event will run until it is finished and it will block all other code including subsequent calls to the timer.
So, the first rule is don't put code in there that will run for a significant fraction of the timer interval.
For example, if your timer interval is 100ms and your code takes 100ms to run then nothing in your code will get a chance to run except the timer. if the code takes 50ms to run then the rest of you app will be blocked for 50% of the time i.e. users can't interact with the app 50% of the time.
Since it's not a good idea to use DoEvents in a timer, any code that is going to block for a noticable period should be put elsewhere with DoEvents in it.
Oh, those Evil Timers!
Timers can be trusted to behave as they were designed to and provide a convient way to do many tasks. Just don't try to use them in a manner they were not intended to be used.
Another thing you should know. About the only thing that's good about timers is the fact that it maintains low CPU usage and its ease of use. That's all. Other than that, they are horrible. And when multiple timers are firing off all at once, that's when slow down and incosistancy really get noticable.
Here ya go. A nice example of a managed loop. Locked at 60 FPS (frames per second)
Reply With Quote
Mark Thread Resolved
