Timers and Performance

[Spellbound]

Is it better to have one timer that runs multiple triggers (with booleans for deciding if they run or not) or having multiple timers on/off when I need them? All my timers run at 0.03 seconds interval.

 

[IcemanBo]

If the triggers are not logicaly connected use a seperated timer for a new system.
Clear/good structure and stand alone-ability is usually better than trying to optimize at details.

 

[ivofena]

I use indexing + Time Periodic event when I need timers.

 

[Spellbound]

I'm not sure I understand. I have 1 timer that acts like a hub, and it checks all the booleans every interval. If a boolean happens to be true, then Run the corresponding trigger.

Is that better or should I just do turn on trigger (periodic timer) whenever I, eg, add a unit to a specific unit group, and turn it off when the unit group is empty?

 

[btdonald]

I think you can create trigger and register TimerEvents instead of use timer. That can make you run multi-actions

 

[btdonald]

I've used trigger instead of timer in my new systems, It work well

 

[kharza]

If you don´t want to overwhelm your system, use events anytime you can if you have many periodic events with very short interval it can cause lag. Periodic timer is mostly used for Ai and spawn, in the most of the other situations you can find another way.

 

[btdonald]

Native timer is limited. I've test trigger timer events wiith over 1k test, it work well

 

[Spellbound]

I barely understand any JASS so I don't really understand what you're both saying :/

@Kharza when you say use events, what do you mean?

 

[PurgeandFire]

The difference is negligible. If you already have it implemented, then keep it the way it is.

Running things on one timer is pretty nice and convenient. However, if you have too many systems that depend on it, you can easily develop bottlenecks within your code.

Picture it this way: you own a factory with slaves as employees. You tell one slave to go club a baby seal. Unfortunately, 10 more baby seals arrive. As such, you send off 10 more slaves to go club them.

Now consider the single-slave case. It is pretty convenient to have one slave club a couple of baby seals for you. But as more and more baby seals are added, he'll have a lot more work to do--and hell, there is only so much clubbing that one man can do. That is where the bottleneck arises.

There are advantages and disadvantages to both methods. With the "many slaves" solution, there are a lot more slaves to deal with/monitor (in wc3 terms, the computer would have more threads to schedule). But since things are on their own timers, they aren't expected to all run at the same instant. There may be two timers that run every 1 second, but one might've started at 0.5 seconds into the game and the other at 0.7. As such, there would be no bottleneck--they end up "completing" at different time periods. With one timer, wc3 may have an easier time scheduling threads, but you run the risk of developing a bottleneck. Ultimately, ask yourself: how well would this run if every single timer was active in this trigger?

 

[edo494]

well, thats astonishing comparision

 

[Spellbound]

The difference is negligible. If you already have it implemented, then keep it the way it is.

Running things on one timer is pretty nice and convenient. However, if you have too many systems that depend on it, you can easily develop bottlenecks within your code.

Picture it this way: you own a factory with slaves as employees. You tell one slave to go club a baby seal. Unfortunately, 10 more baby seals arrive. As such, you send off 10 more slaves to go club them.

Now consider the single-slave case. It is pretty convenient to have one slave club a couple of baby seals for you. But as more and more baby seals are added, he'll have a lot more work to do--and hell, there is only so much clubbing that one man can do. That is where the bottleneck arises.

There are advantages and disadvantages to both methods. With the "many slaves" solution, there are a lot more slaves to deal with/monitor (in wc3 terms, the computer would have more threads to schedule). But since things are on their own timers, they aren't expected to all run at the same instant. There may be two timers that run every 1 second, but one might've started at 0.5 seconds into the game and the other at 0.7. As such, there would be no bottleneck--they end up "completing" at different time periods. With one timer, wc3 may have an easier time scheduling threads, but you run the risk of developing a bottleneck. Ultimately, ask yourself: how well would this run if every single timer was active in this trigger?

Man, those poor baby seals.

The game should still run quite well with the amount of triggers that are running from the 1 timer, but I don't know yet how many more triggers will go in there so I can't really tell at this point in time. From what you said, I think I'll just have to have a few timers that run at varied speeds eventually, though I sort of tried to bypass that by making each trigger add up a bunch of indexed integers to simulate their own seconds (an integer reaching 33 is around a second in time if I'm not mistaken, and it returns to 0 afterwards to start counting again). This way, if I have, eg, an orbiting animation I wanna make, having one start when another is halfway through its 'second' would mean they each have their own timers, in a way.

I'm not sure if that made any sense, but thanks for that amazing explanation