If I set a variable with this snippet on tick, is that expensive? Is this cheaper than casting? If so, why?
Event tick runs every frame, absolutely everything you put in there is expensive because for every frame that actor is active and ticking that code gets run which can very quickly add up to performance issues.
Ideally you want code only to run when it must run, and not when it doesn’t have to, event tick just runs it always.
You can fairly often substittute event tick with timeline or a custom event coupled with an event timer.
You can also optimize your event tick by toggling ticking on and off depending on whether it is needed.
Sometimes though you have no choice but to use event tick.
As for the get player character world location nodes, they’re very cheap so you don’t have to worry much about it, a get like this is generally very cheap. It’s more about what you do with the get results, math nodes for instance always cost something. It’s all a balancing act in the end, but one of the easiest ways to optimize a game is to move things away from event tick lol.
1 Like
You could cache the capsule component to a variable once and then just get it’s location.
But the promotion of the capsule component to a variable would have to be done outside of the tick function.
This would reduce the complexity from
Get Player Character → Get Capsule Component-> Get Location
to
Capsule Component Cached Variable → Get Location
So 1 step
Still not promoting tick as a function, but if you have to then optimize it to the max.
Event based actions / calculations are always the better option.
1 Like
This reinforces an old narrative about ticks being prohibitively expensive which is not healthy at all.
Tick is not evil, and should not be avoided like the plague at all costs, you use it when you have to.
You’d be surprised to see just how many things are ticking in the engine all the time, doing things considerably more complex than getting an actor’s location
Timelines are literally components that tick, and do even more stuff on tick than just call a get actor location function
It is true that everything is a balancing act, and limiting ticking actors is generally good advice, but it’s harmful to say never do anything on tick, because it makes people confused, and we get threads like this
Some results after some profiling on my machine:
BP Actor with GetPlayerCharacter(0)->GetActorLocation() on Tick: 3.5ms for 1550 ticking actors
Not great, but a bit unrealistic as well to have this many
C++ Actor with GetPlayerCharacter(0)->GetActorLocation() on Tick: 0.77ms for 1550 ticking actors
Much better, can be fine depending on the rest of the game’s logic
So having one tick that does this is totally negligible. If anything, I would advise you to use C++ for anything ticking, since the overhead of blueprints can add up when running multiple times every frame
But please, always profile, use Insights, it’s built into the engine and can provide all the answers that you need, in great detail
My go to for profiling when I’m interested in blueprint performance is:
stats.namedevents 1
trace.file default,assetloadtime
Alternatively, from the editor:
From my profiling:
C++ actor:
5 Likes
Agree with Zeaf,
my advice, is make the game first and then go back and see where your bottlenecks are. while its always good to keep performance in mind, it can freeze your development.
1 Like
I didn’t say it was evil, and I didn’t say to never do anything on tick, I said performance issues add up quickly, and your post only supports that fact. I also said gets are cheap and he wouldn’t have to worry about them, which your post also supports, 1550 for a 3ms cost is measurable, but it sure is cheap.
1550 ticking actors with only just get actor location are making a quite more so notable dent than ones ticking without a dent. The case of someone just putting a simple get on event tick and nothing more is very rare.
I wonder how much those numbers change if you add some math in there, throw in a simple division and see how much that affects these numbers. Gets should barely have a measurable cost but math operations are different, I’m actually kinda curious just how much more 1550 divisions per second would cost.
You’re spot on about using the profiler to troubleshoot performance issues though, I also quite like the gpu visualizer.