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.
This is a good read: https://eryn.io/gist/3db84579866c099cdd5bb2ff37947cec
@LucasTutoriaisSaimo That is just a opinion from Kampfkarren, not a actual proved fact.
Any wait() method from Luau is just bad.
This is a completely subjective statement, there is no need to argue pointlessly when you don’t know much about how it works internally.