That test has many different issues. First of all, those numbers only go that low if your running at 10 fps. Those numbers would be dramatically similar if you were running at 60 fps. Also, good optimization reduces the amount of lag in the server, causing higher fps in the client. In a 60 fps benchmark, wait() and Heartbeat are dramatically similar. However, if the given client FPS gets too low or too high(Roblox FPS Unlocker I’m looking at you), Heartbeat will prevail by a large margin.
That isn’t my point, the test was to show how Heartbeat.Wait is much superior and reliable than wait on throttling. There is no need to use Heartbeat.Wait if your code is event based and doesn’t yield threads much.
while I do agree with you that HeartBeat:Wait() is much, MUCH faster than wait() in most situations, the evidence you used to provide usually wouldn’t happen in most games. (most laptops and computer can easily run games at 60 fps), phones can run adopt me at 60 fps.
When you want precise and accurate yielding, Heartbeat.Wait is needed. Also, these both are also affected by how many threads the code has to resume, not only FPS. Heartbeat.Wait is added to the primary queue since it’s not bound to the 30hz frequency unlike wait, which is added to the secondary queue. Your point isn’t valid at all.
Big developers answered to this post agreeing. Using .Heartbeat and stuff is just better. In this case at least right now, since they’re gonna be replaced soon.
Anyhow, it’s not hard to implement your own system to use .Heartbeat or .Stepped, or even .RenderStepped (on the client).
No, when you don’t care about accuracy, wait(n) and wait() are completely fine. Also, assuming your code doesn’t yield threads much and there isn’t much FPS loss, wait is as accurate as it needs to be.
Anyhow, it’s not hard to implement your own system to use .Heartbeat or .Stepped, or even .RenderStepped (on the client).
Is this relevant?
You don’t know about the problem with wait() some performance issues? Wait let me find it.
Of course I do know about the problem, that’s why I have posted a few replies to this topic. Please don’t be subjective and rather reply with facts and not questionable points. Consider learning how wait and Heartbeat work internally.
Ohh, ok now I understand why wait() is bad. Thank you for linking the post on how wait() works. Thank you for that.
If you are keeping your secondary queue tidy by using these alternative methods, then making timers with wait (like wait(30) ) can be okay, as long as you’re okay with it not being exactly accurate.
I’m okay with it not being completely accurate, considering it’s a minute long.