At present time my game my game barely reaches 60 FPS on a modern and powerful graphics card with textures no more than 1K, and it does not have ultra-realistic graphics. I suspect the problem is in the Blueprints, not in the graphics. So, which node do I have to verify first, which must not be executed multiple times per tick as they are very slow? I think one of them is “Get All Actors of Class”, which are the others?
Ticking Loops.
1 Like
Hey @Etyuhibosecyu!
Another thing to remember is that anything that has tick enabled is using it, even if there’s no code after that. Which fundamentally is a very small usage- however, if you have a lot of actors, say, instanced actors etc with tick enabled that can definitely contribute. As a good practice, I just delete the tick node when I make a blueprint to guarantee it is disabled and only pull it in if needed.
In other words, this alone contributes to processing use:
You want this, or this.
Hope this helps!
2 Likes
Hello @Everynone and @Mind-Brain! Is it allowed to perform some actions, that must be executed periodically but not mandatorily at each tick, in the following way?
(Event is called from Begin Play.)
It will work OK-ish but why do it? Delays are notoriously difficult to debug.
- why not have a timer that we have an actual control over?
- or lower tick rate of any actor / component. Here, 4 times per second.
- if you have a lot of actors that need to perform something in a timely (ehm), manner, you can hook them up to a single timer in a Timer Manager actor; Dispatchers are great for this since you do not need to loop once the initial cost of setting them has been paid. It could look like so:
Everyone subscribes and listens to the dispatch.
- the above could also become an organised way to stagger updates, spread them a bit across time so not all 1000 bullets update in a single frame, causing a hitch.
Perhaps your project is advanced enough to start digging into:
@Everynone, is this solution bad, without the Event Dispatcher?
(Event is called from the Begin Play of the Game Mode.)
likely yes, why not just start the timer inside the enemy itself? this will also let you save the Timer to pause/resume later.
1 Like
I like it. One timer to rule them all. Running one timer is better than running 100 timers.
However, it’s generally what you run on Tick / Timer that causes issues rather than the Tick / Timer itself. You can still attach something attrocious to the update 
.
1 Like
@Everynone, “one timer” means one event with iterating over all actors (to at least check if some of them is enemy) each second? Or is a timer for each enemy, but without the all-actors loop - better?
Only if it’s very badly implemented.
@AlienRenders So you’d give each of the 1000 actors a seperate timer even thought they need the same update? Asking for a friend.
Isn’t what I am suggesting a common, and agreed on thing?
Thanks for a joke 
Could you explain what are you suggesting in the more detailed way?
You are delegating. This is a dispatcher. You just can’t send any data. But perhaps you do not need any.
I’ll pillow fight anyone who says it’s a bad idea.
@Everynone, but what is faster - a timer for each enemy, one timer with “Get All Actors of Class” node and loop, or something third?
I doubt you will be able to measure the difference until you go into thousands. I say a single timer will perform better and have a lower memory footprint (?).
Happy to be corrected, though.
This should be easy enought to test.
If a 1000 timers is a bottleneck, find a new engine.
1 Like
It is not, no one is saying it. The question was what is more performant. 1 vs 1000.
That’s the reason you have managers, pools. Besides that, measuring perf in BPs is an effing maze, it scales in a linear way but weirdly.
You get very different result PIE and in packaged.
There can be nuance in what’s needed though. Are the list of actors static or dynamic? Can it grow? How are you tracking the list? Are you using GetAllActors? If so, then a single timer is NOT going to be faster. There’s also simplicity factor. Having each actor track its own decisions is simpler and less error prone.
I’m writing a tower defense game and I have TONS of timers for all sorts of things. Animations, firing, path finding, etc. I have timers everywhere. It works great… though I’m in C++. They don’t all trigger at the same time. Even if they did, who owns the timer? Who makes the decision to trigger it again or to stop it?
The way it’s explained right now is as if Unreal Engine is like the game of Space Invaders where the fewer aliens there are on the screen, the faster the game runs because there are fewer things to handle. Swap out aliens for timers. I think we’re a little beyond that.
The TimerManager who lives on top of everything else. Sometimes you make the decision. Sometimes the manager makes the decision because it does rely on world tick delta. You can give it less or more work to do.
My fav bit about the timer is how it fires multiple updates between the frames. If you ask it to run faster than the framerate, you’d expect these to be distributed evenly but they are not. At which point we’re talking about platform time.
My advice would be to not guess. It’s very easy to optimize the wrong thing. Do some profiling and eliminate the guesswork. Use Unreal Insights. Once you have actual numbers, then you can decide what needs to be looked at and optimized. There are also stats you can display on screen to know if it’s GPU or CPU.
1 Like