# Will having many timers affect my game performance?

I'm making a game for android, and earlier today I was trying to add some cool stuff to my game. The problem is this thing needs like 5 timers. I build my timers like this:

timer += deltaTime;
if(timer >= 2.0f){
doStuff;
timer -= 2.0f;
} // this timers gets stuff done every 2 secs


Will having to many timers like this, getting checked every frame, screw up my games performance? The effect I wanted to add was a crosshair every 2 sec, then remove it after 2 sec and do a timed animation. So an array of crosshairs dependent on a bunch of timers to be exact. This caused my game to shut down when used, so thats why Im wondering if using that many timers causes my game to flip out.

• i don't get if you are experiencing actual problems or you are pretending having one. Sep 15 '12 at 17:02
• what? Its a simple question, "will it screw up my games performance having to many timers like this?" cus I plan to have more, and I want to find out if I can do it this way or if I need a new way, that is more performance-friendly. Sep 15 '12 at 17:08
• how much is "more" ? That's the problem with your question, it's not clear and can't be answered because you do not have set any boundaries. Sep 15 '12 at 17:58
• " timer -= 2.0f;" Makes little sense even though it looks logical. Why not timer = 0; ? Sep 15 '12 at 22:57
• Resetting the timer with timer = 0; does not make the timer trigger every 2 second, so that would be wrong. Instead it will make the next one trigger after at least 2 seconds from the previous one even if the previous one was late. Sep 16 '12 at 5:49

## 3 Answers

It's not the short timer code you posted, any number of those would be fine, it's what doStuff you do with each one.

One problem I can foresee is that if you have timers of different frequencies some of them will sometimes "beat" and trigger their doStuff code all at the same time. For example, if you have a timer for 2.0 and one for 3.0, then every 6.0th tick both actions will get called simultaneously and maybe cause your game to burp when that happens.

Pick timer frequencies that won't all gang up like that, problem solved before it happens.

The question of "too many timers like that" can only be answered by asking "what do those timers DO" and then profiling to find out how much work you can afford and keep running smoothly.

• thank you! I never thought if frequencies. I'm pretty sure this problem isnt frequencies tho as the second timer wont start until the first timer finishes. (if timer1 >= 2.0f){add object to array with built in timer thats dissapears after that timer reaches 2.0f();} But this will help me in the future for sure. Sep 15 '12 at 17:20

"Will X affect my game's performance" should always be answered by "profile it and find out". Anything else is just guessing.

• I understand that know. But since I have no experience with building a large game I thought someone that had would be able to answer if using to many timers is a poor way to execute code. Didnt know it would be such a big deal to people that I didnt give the EXACT amount of timers I planned on using. And wanted to avoid having to re-do half of my games functions just because I used poor code. there is a difference, imo, in an experienced guess and an unexperienced one. Sep 16 '12 at 17:30
• A number of data manipulations, sorts in particular, have specific breaking points where using one is better than another when over a certain count. That's mostly why people are concerned. Sep 17 '12 at 0:59

The timer code itself shouldn't have any noticeable performance impact. It's just a few lines of code, after all.

• "X shouldn't have any noticeable performance impact. It's just a few lines of code, after all." lol sounds like the opening to CS horror movie. Sep 15 '12 at 23:07
• Someone should totally make that. Sep 15 '12 at 23:21