Isn’t renderService.Heartbeat faster?
Either runservice heartbeat or renderstepped
(note: if your game is laggy then you shouldn’t use thisbas it will be even slower than wait())
What do you need this for? Different methods are better for different purposes.
there’s really nothing unless you use task.wait(0) like what you did in the post
Hi,
Instead of a faster wait, you should instead group some tasks together.
Let’s say we have 10000 parts we want loaded, but we cannot do it all at once without lag.
And if we use task.wait() for each part we load in, then it’s gonna take a while.
Instead we group them into parts of 250. Meaning that instead of 10000 task.wait()'s, we only use 40.
This is true, but be aware that too many operations in one frame can be a problem if you’re not handling it correctly.
But to answer your question directly, it kind of depends. task.wait()
is the same as RenderStepped.Heartbeat:Wait()
. Heartbeat
runs every physics frame (which is 60 fps) after physics have been calculated. RunService
has multiple other options for example when you want to jump in. Such as before a physics frame.
Here’s a list from RunService:
Technically the fastest delay would be RenderStepped as this is the FPS you’re probably thinking of. It’s only client-side, but it happens prior to every render frame. This will be faster as it matches with FPS even if the user is using an FPS unlocker (going above 60 fps). But it’s important to note that that this should only be used for render-specific things and can cause issues if not handled correctly. For the majority of cases, you should just use task.wait()
.
Yea, I’m sure everyone knows that the more stones you put onto a scale, the more it weights.
Note that my quotation was not to reply to you directly, I’m sure you were aware of that already. I was simply referencing it to explain a potential danger for those who are unaware. There’s a wide range of skill levels here on the developer forum (and obviously Roblox in general), so I prefer to cover things more in-depth where possible and realistic. Anything can be a learning moment.
Yea that certainly makes sure that everything is accounted for.
local function FastWait(Time)
local Clock = os.clock()
repeat until os.clock() - Clock > Time
return os.clock() - Clock
end
local Time = FastWait(0.0001)
print(Time) --0.00010019994806498289
This is not a “wait” function. This doesn’t yield- it executes 0.0001 milliseconds of work. This won’t give other threads the ability to run like task.wait() can.
It is a ‘wait’ function in that it waits for some length of time before continuing (busy waiting). I know it doesn’t yield but there was no mention of that being a requirement in the original post.
I was wondering if there was anything faster than task.wait(0)
is there a way to make it yield?
If you want to keep it simple, you can just use RunService. There are several different events you can yield for, such as Heartbeat, RenderStepped, Stepped, and some others.
I’ve already mentioned it in my previous post.
The most you can do, that I know of, to make that os.clock example “yield” is by removing the math operation and just doing this, using about the same code:
function FastWait(yield)
local clock = os.clock()+yield
repeat until os.clock() >= clock
return os.clock()-(clock-yield) -- This line can be removed if you don't care about a return value.
end
print(FastWait(0.0001)) -- 0.00010000000020227162 (Time may vary, but barely.)
If you remove the parenthesis on the return part, os.clock()-clock-yield
will always return 0.0001
(or whatever your input was), but negative for some reason.
u can also use RunService.PreRender or task.defer(function()
The fastest wait function is the negligible time between execution of each line of code, while true do end is the supreme method of scripting
task.wait() will wait for a frame, it’s tried to the framerate, so 1/60 of a second if the fps isn’t unlocked and isn’t lagging. So, if you want to go faster than that, you’ll have to run (the function, or whatever you want to run) more than once per frame
not quite a “wait”, but there’s task.defer
it can go pretty fast for some odd reason that i don’t know about
downside is that you can’t stack defers past 80 defers
for some reason 80 defers is still much less than 1/60th of a second (at least in the server)
if we add in parallel coding, you can use this hacky method with task.desynchronize and task.synchronize to bypass this defer limit
funny
yeah, i literally said before that task.defer exist. But i didn’t know about the defer limit bypass, thanks bro!
Dont you mean RunService? I dont think renderservice is even a thing