wait had restrictions in that it had an internal throttler which caused
wait calls to become extremely unrelieable past a certain point, which is no longer the case with
task.wait. The performance difference between
task.wait and this module has gotten smaller, which means this module should only be used if you either seek extreme precision, or to yields hundreds of threads in parallel. 99% of the time, you won’t need this module anymore
I’ve recently been working on a custom implementation of Roblox’s wait function, and my main source of motivation for this was due to the fact how poorly Roblox’s yields scale when using wait. Basically, this is a custom task scheduler.
This is a pure Lua implementation so sadly it doesn’t have a huge edge against Roblox’s, but through my benchmarking it is still way more performant.
This module uses uses
os.clock instead of
tick for performance reasons, which as a bonus would return more accurate yield times (7 or more decimals).
As this uses the .Stepped event, this supports faster yield times than Roblox’s default (1 / 30).
The main concern in a lot of Roblox games is that they use the
wait function. Like, a lot. This is more bad than you may think. Firstly, this can clog up the task scheduler very easily, and deteriorate the state of your game very quickly. @CloneTrooper1019 has demonstrated this issue, as seen here:
Yeah… Pretty bad.
So, how does this module address this? Simple! This module manages your yields for you, and instead of letting it update and check for every yield, it simply stores them in an arrays and iterates over them. This is a better solution since you would converse back and forth less with the C API, thus sparing Roblox it’s resources.
TLDR This module makes sure your game will always have only one yield updating at once, making your game not die from having a filled task scheduler.
Source code can be found here: RBXWait/Source.lua at master · PysephWasntAvailable/RBXWait · GitHub
number YieldTime, number CPU Time