You saw the title, which one is faster, task.wait() or task.wait(0)? or does task.wait(0) just default and wait the same amount as task.wait()?
2 Likes
I think zero is still zero.
Task.wait() is basically nothing and so is Task.wait(0).
2 Likes
The minimum wait time is one frame (usually a 60th of a second).
task.wait()
task.wait(nil)
task.wait(0)
--all the same lengths
5 Likes
The minimum amount of time a task.wait can handle is 1 frame. A higher framerate means that you can go even lower. Therefore, putting a nil, a 0, nothing or any lower number would result in it going back up to 1/60 i.e ~0.0166666 seconds. You could get it lower by using FPSUnlockers but not everyone has them.
3 Likes
Why doesn’t Roblox make it so task.wait(0) waits 0 seconds?
because then it would have no purpose, that line would be redundant because it’s basically waiting for no time at all.
Yes, but what if you’re running a script, it’s automated, and say you’re passing some random number to task.wait() with full understanding that it will have a chance to be a small number like zero, I would want to wait 0 seconds?
you could make it if it is 0 seconds, just skip the task.wait()
An example:
local waitTime = 0 -- changes, as you want it
if waitTime ~= 0 then
task.wait(waitTime)
end
1 Like
I’m not exactly sure why you want this behavior.
local function Wait(Time)
if Time > 0 then task.wait(Time) end
end
Wait(0) --no wait
Wait(1/60) --wait 1 frame
1 Like
I don’t “want” it, it’s just not logical to have it have that behavior. A person unaware of this could pass 0 into the function thinking it won’t wait at all, and then their code is running on a whole new frame.
It seems counter-intuitive and I want to know why.
it’s really not counter-intuitive, there is no purpose for 0. Plus, it is kinda obvious that if you dont need to wait, just dont include it.
You aren’t understanding what I’m saying. Code can be unpredictable, and there may be an instance where you pass 0 to the function for ANY reason. It doesn’t matter.
Anyone passing any value to it will be expecting and desiring it to wait for that amount, so if they just happen to pass zero (so don’t wait at all, continue) they expect that functionality. Can anyone tell me why it instead waits until the next frame?
That’s such a weird case
If they’re aware they can end up passing 0 to the function, the person in question can just do a check similar to one Forummer posted
Additionally, depending on your framerate, waiting one frame will make little to no difference
Likely for the same reasons why task.wait(nil) waits until the next frame. If you’re calling the function, it should be to yield your code for a certain amount of time; if you’re calling the function with the intention of no yielding, that doesn’t make much sense
Still doesn’t make sense to me. If I pass 0 through the function I have the intentions of it not waiting. It shouldn’t not make sense, because that’s the purpose of the function, to wait the exact amount (or as accurate as possible) you tell it to.
1 Like
I don’t think you are understanding what we are telling you. If you pass in 0 to task.wait(), it will still call the task.wait() class, passing in 0 as the time parameter. It is the exact same thing as passing in nothing at all.
There is no explanation to why Roblox made it this way other than that is how the function works.
EDIT:
As @Forummer mentioned, if you are truly that concerned about passing in 0 as a value and it still calling task.wait(), just make a function that will either call task.wait() or skip the call depending on the value of the time parameter.
1 Like
I do understand, I already knew they were similar, I was just curious if one faster regarding microoptimizations.
Yes, I will instead take this path. I do think Roblox should change that.
You can’t micro-optimize this. Both cause the script to yield, which will in turn wait at least until the next frame to resume. Neither will cause anywhere near a significant measurement in performance degradation to delay the next frame further.
3 Likes
Not trying to. Wondering if one is faster than the other because of the way it’s written internally. I’m working on scripts right now that need to be very consistently timed with task.wait().
I got my answer though. Turns out they are the exact same. Thank you for the assistance.