Heartbeat is worse than while true do wait()?

[EncryptionKeys]

Hey! I recently was discussing heartbeat with a discord member in a server I am active in.
They said something that I wasn’t too sure of, and I wanted to make sure that they were right when making their claims, as they seem to make heartbeat worse than wait.

Is this true?

Thanks in advance!

[Sir_Highness]

Heartbeat rate is variable, but I don’t think you’re gonna ‘beat’ it with wait(). Heartbeat supplies the ‘dt’ so you can account for the fps achieved at any given time. If there is any contention for resources the hearbeat is gonna happen before wait() which would be a lower priority in the schedule. (I think)

[Pokemoncraft5290 (Based)]

No it isn’t, heartbeat uses client fps if it’s being used on the client.

[amadeupworld2]

This is incorrect, heartbeat has its uses for different applications.
As it says in the screenshot, heartbeat runs after rendering, meaning that it should be used if you want to run something every frame which doesn’t involve rendering.

For example, manipulating the camera or player input should be done on renderstepped. However, if you have a lot of code in renderstepped which doesn’t involve rendering, it could lag your game, which is why hearbeat would be used in those cases.

[ItzMeZeus_IGotHacked (notzeussz)]

Your friend only described the downsides of Heartbeat.

wait() is a code smell, and it is only useful if you are yielding a thread with smaller numbers, however if you use it to yield a larger number, that is where this function will be broken as it will yield longer. RunService.Heartbeat fires AFTER the physic simulation of the game is completed inside a frame, even though it might not be better when comparing to wait() when yielding a small amount of time, it is extremely useful for higher yielding.

However, task.wait() is basically the best option since it yields the thread for an amount of seconds then resumed it on the next Heartbeat event, but task.wait() still has the same code smell as wait(), just slightly more efficient.

[ItzMeZeus_IGotHacked (notzeussz)]

@amadeupworld2

As it says in the screenshot, heartbeat runs after rendering, meaning that it should be used if you want to run something every frame which doesn’t involve rendering.

False, Heartbeat only fires when physic simulation in the game is completed inside a frame.

[AstrealDev]

@ItzMeZeus_IGotHacked

but task.wait() still has the same code smell as wait() , just slightly more efficient.

IIRC this is incorrect and task.wait() is actually equivalent to RunService.Heartbeat:Wait() with a few optimizations. wait() is not the same as either and under the hood uses an entirely different method of yielding.

[ItzMeZeus_IGotHacked (notzeussz)]

@AstrealDev

IIRC this is incorrect and task.wait() is actually equivalent to RunService.Heartbeat:Wait() with a few optimizations.

False, here’s a reply about why:

Task Library - Now Available!

It should be noted that results of these aren’t equivalent: task.spawn(function() print(task.wait()) end) task.spawn(function() print(game:GetService"RunService".Heartbeat:Wait()) end) task.wait()'s DeltaTime result will count from the time of the call, while Heartbeat:Wait() will count from the previous Heartbeat. Also, task.delay() causes a crash instead of an error.

And you should probably read the announcement better as it said:

@WallsAreForClimbing

Yields the current thread until the given duration (in seconds) has elapsed and then resumes the thread on the next Heartbeat step.

[AstrealDev]

Ah that’s really interesting thanks for correcting me

[D0RYU (nici)]

@ItzMeZeus_IGotHacked

False, here’s a reply about why:

@WallsAreForClimbing

task.wait()
-- is equivalent in behavior to
RunService.Heartbeat:Wait()

right here they say that they are equivalent in behavior

EDIT:
saw your second quote
that guy talks about what they return, which isn’t really behavior

[ItzMeZeus_IGotHacked (notzeussz)]

But still, it does kinda give a bit hint of the behavior according to whatever’s that’s returned.

[D0RYU (nici)]

they still behave similarly either way, I don’t think WallsAreForClimbing was even talking about what they return at all

[ItzMeZeus_IGotHacked (notzeussz)]

I am just giving him a suggestion about yielding, although yeha that’s off topic by still worth to bring it up.

[dthecoolest]

Nope, first one is just bad coding if that situation does happen with stability problems in low fps. Heartbeat is able to account for game slowdowns with the use of delta time. However the programmer must be able to take into account of this in their game.

Additionally wait() has it’s own stability problem proven with known big game developers like clone trooper in their test replication, wait() is also frame dependent if you look at the task scheduler article.

Edit: I believe this is because wait() is limited to 1/30 of a second while heartbeat is 1/60, they will never change this because this might cause problems in users code (they might wait() for a service to load at the top of the script). Article about it being 30 Hz or 1/30 of a second.

Another visualization of why Roblox's stock wait() function is broken.

Second claim heartbeat is based on servers fps is just false, it’s client fps.

That is why you commonly see people having issues with the opposite instead where the client uses fps unlockers and the code doesn’t account for that decrease in delta time.

[EncryptionKeys]

Thanks you! And everyone else who answered.

I didn’t expect this topic to get as many replies as it did!

I still have to read some of the replies for a better understanding.
Thank you all again!