• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Timers and Performance

Status
Not open for further replies.
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?
 
Level 4
Joined
Jul 25, 2014
Messages
57
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.
 
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?
 
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 :D
 
Status
Not open for further replies.
Top