I’m curious about the performance cost of delay nodes. If I have a delay with a value of 600 (10 minutes) is it more expensive than a delay with a value of 60 or 6? Or does it not really matter?
The answer to this question depends on how you want to use it. If it is just for a short time, then the delay node will work just fine otherwise an alternative way needs to be considered.
The delay node is use to put a Pause when executing a function/event and it is always meant to be used this way. While in case of 10 minutes delay it is not ideal for this delay node to be used.
A better approach that we used for such a case is to use the “Time Event” function. It allows a more efficient way of executing and non-blocking/pausing.
It just set the timer length, no difference.
2 Likes
In the sense of using time, yes both are about setting time. Basically what you are saying here is the same as playing football and playing basketball are both a sports game. But the rules and the way of playing them are different. The same applies here.
Time events are used for tasks that need to occur regularly, updating the game world, checking for collisions, or triggering events on a timed basis.
Delays are often used for tasks like creating timed animations, controlling the timing of game events, or creating delays between actions in a program. The delay you specify may not be accurate to the elapsed time.
That’s the obvious difference between using ‘sleep’ or ‘setTimeout’ in programming (delays) can cause your code to be unresponsive for a certain time, unlike time events.
They’re just latent actions under the hood, they run a counter in C++ which triggers the output node once it is finished.
The bigger question is not performance but how you will end up structuring your code. A big bunch of delay nodes easily becomes a tangled mess impossible to manage. You might want to rather count the amount of time passed and then send the event or something similar.
Agreed.
In a sense, counters are not to be used in this loop counting. It is more likely you could say time stamp check.
// Function to be called after the delay
void YourClass::YourDelayedFunction()
{
// This code will execute after the delay
UE_LOG(LogTemp, Warning, TEXT("Delayed function executed."));
}
// Function to start the delay
void YourClass::StartDelay()
{
// Set the delay time in seconds (e.g., 5 seconds)
float DelayTime = 5.0f;
// Create a timer handle
FTimerHandle TimerHandle;
// Set the timer to call YourDelayedFunction after the specified delay
GetWorld()->GetTimerManager().SetTimer(TimerHandle, this, &YourClass::YourDelayedFunction, DelayTime, false);
}
Timers are a bit different yes, I was replying to the main post more or less though. Not sure if I’m using the forum software wrong or w/e. The stamp is necessary so the timer handle can be manipulated.
1 Like
Yeah, I realize what the purpose of the delay is. I’m just curious if there’s an overhead to using it in ways that it’s not necessarily built for.
I played around with different delay lengths with StatUnit on, and it didn’t seem to make a difference. At least not with a single delay. Maybe if you’ve got hundreds of delays all running at the same time you’d notice a difference? I should do more experimenting