Hello! I was wondering what the best wait time should be for a while wait() do loop. I have a code where I want to see if a player is within a certain distance (.magnitude) and if they are, then a value is set to true. Vice versa if not.
Should I use while wait(.5) do, a different wait time, or something entirely different? Thanks!
You can try and use RunService, they provide a RenderStepped event which is a good alternative for while true do loop to prevent exhaustion of script.
game:GetService("RunService").RenderStepped:Connect(function()
-- Add the looped code here
end)
Quick question, does that fire every frame or every input entered?
I recommend having a wait time around 1 seconds - I don’t think it’s really necessary to check every 1/30th of a second for a player lol. I also recommend not using wait(n) as a condition for a loop - it’s not encouraged practice and is a bad habit.
EDIT
Using wait(n) is fine - it’s wait() that has underlying issues (unless the number wait is given is so slow it has the same issue).
For every frame that’s rendered prior to the unrenderred frame, this event will fired. I think. You can check the API docs for more informations.
Won’t that cause more script exhaustion since its being fired almost every frame, compared to a while wait(.5) do that’s only fired every .5 seconds?
Sorry if I’m asking a lot, I’m just very interested in programming and wanting to learn a lot about it! 
RunService is more efficient. If I’m correct, if someone runs this on a low device or their FPS is really bad, it will take like 0.6 secs to fire that event. Otherwise, it will have like a small millisecond delay.
While true loop is really inefficient since it exhausts the script easily, making low devices unstable.
Yes, a while wait(.5) do will create less work, but if you want it to be quick you should use renderstepped.
Oh so it scales depending on device capability (basically). Thanks for the info!
If you plan on using RunService, I recommend using Stepped - RunService only executes on the client. HeartBeat may be a good alternative as it’s on both the client and server, but it executes after physics renders. I recommend using Stepped as it executes before physics renders. Corrected by @colbert2677 - I recommend checking out his reply
EDIT
@JarodOfOrbiter I don’t recommend that article - although Erik Cassel, former VP engineer of Roblox (may his soul rest in peace), wrote that article, it doesn’t fully cover why wait() is so bad. It talks about some of the effects of what could happen, but not what’s causing the problem.
EDIT2
Yeah, I agree the article brings up good points, and is good starting food for thought - I just don’t recommend it because it doesn’t go too in-depth as to why wait(n) is causing the “lag”. It makes good in bringing up performance analysis, but simply recommending to increase the wait time doesn’t solve the problem. For example, it doesn’t touch on about using event-driven programming where it can be used over a loop with wait(n). It also doesn’t really expand upon Lua’s task scheduler, which’s the major reason why this occurs in the first place.
What you really want to do is just avoid expensive laggy functions on quick repetitions. Not everything needs to be fast. Give this a read. Bear in mind that it predates Renderstepped, but that as RenderStepped runs 60 times per second, you should avoid RenderStepped too.
https://blog.roblox.com/2012/05/using-wait-wisely/
EDIT
Communicating with edits, @TheeDeathCaster I like it. I assume OP is familiar at least in part with why waits can be bad, but the article is oriented to beginners and gives some loose advice on the subject. I does not give any wrong information either. Is it what was needed? Maybe not. But it takes almost no time to read through and does have some good points.
I only want the script to run on the client because it will be showing a UI for the client if they are within a radius.
You could probably use RenderStepped, as it would execute before a frame renders - but I recommend using Stepped regardless, as it executes before physics renders, keeping it more consistent with the rest of the game. Corrected by colbert2677 - I recommend checking out his reply
Getting back on topic, you don’t need to use RunService - wait(n) is fine to use as long as you’re careful with it. It comes down to the simple question: how often does my code need to execute? Every second? Or every other second? Answering that simple question will give you an idea of how often your code actually needs to execute.
while wait(n) do is not a bad practice. It’s valid. People are just saying that it’s a bad practice most of the time since it doesn’t make sense that “while the wait duration is truthy do”
while true do end is objectively better than the while wait() do end. The former is clearer and clearly indicates that the loop is infinite. This is out of the scope of the OP though; so if you want to learn more feel free to dm me and I’ll happily explain in-depth.
I’ll also leave this.
Welp… after reading everything I feel the same… I like to use RunService everytime I can but I always feels that is more demanding because is firing each frame. But everyone says that is better due to the exaust the wait causes…
So… I dont get why… So executing an expensive loop 60 times in a second is better than just execute it 1 per sencond?..
This is because he wants it constantly check and don’t wanna have an exhaustion. Using while wait(1) is pretty bad since it only detects every seconds.
wait(n) is fine to use - it’s wait() that creates issues. RunService’s events (HeartBeat, RenderStepped and Stepped) executes with physics rendering, it doesn’t quite have the same problem wait() does.
To reiterate something I said prior,