As I explained, it’s for very fast times, and when you want loops to run faster, did you look at the first test? Decrease the 100000 to lower if you would like. That should prevent lag.
If your code requires you to rely on randomness, it is not effective. Plus, this code is not at all for “fast times.” Waiting at a random chance would cause the total wait time to be inconsistent.
Yes, if you would like, there is a non-random way. Would you like to see the code with that?
I do not think this “non-random way” will be any more effective than task.wait. I’ll take a look, though
1 Like
Ok, like i said previously in the post, just use that for almost everything you could want to do, this was just for fun.
The way I was thinking of did not work, but the reason why I did not mention the inconsistency in wait times is that real wait times also have the same, if not more inconsistency (at least with wait). The chance of the random being picked if you just wanted to wait for a very small time, is very small. The main idea was to see how quickly a loop could go, without crashing.
Why? Just why? You do understand that you’re completely relying on RNG that this thing even work right? If the RNG is having a really bad day, there goes one player. There’s so much to say about the code here.
- Why are you localizing globals in the function?
- Why are you checking
tick or os.clockif tick will always exist? It’s going to get deprecated, not removed. - Same thing with
math.random or Random.newbut the API for Random.new is different. - Why is true being returned? You better not be trying to make it compatible with the while wait() do idiom. wait() and task.wait() returns the elapsed time.
1 Like
- To make it look more concise.
- tick does not work on the luau demo page, so just added it as an extra precaution.
- I have never used Random, so thanks for correction, I thought it might also be replacing math.random.
- Thanks for letting me know, I have never needed the time returned.
This was only a fun way to make loops that ran faster than normal, yet still waited and did not crash.
This is just a stylistic note here (I promise I’m not piling on the rage train!!!), but readability should always be prioritized above concision. Remember, we aren’t being charged by the character or by the line here! Truncated code also doesn’t give you any performance benefits. A great rule of thumb is that good code should be able to read like plain-text
Example
Code 1 - reads like plain English
local Players = game:GetService("Players")
local WhitelistedUsersIds = {
1,
2,
45,
73,
97,
}
--// Preceding code/sub-functions also reads easily so that anyone reading it should be able to understand the logic pretty easily
local function CheckIfPlayerIDIsWhitelisted(PlayerID: number)
local FoundInWhitelistTable = table.find(WhitelistedUsersIds, PlayerID)
if FoundInWhitelistTable then
return true
else
return false
end
end
--// Core code reads like English - even a non-programmer could get what is going on pretty easily
Players.PlayerAdded:Connect(function(Player: Player)
local PlayerIsWhitelisted = CheckIfPlayerIDIsWhitelisted(Player.PlayerId)
if PlayerIsWhitelisted then
print("Whitelisted Player Found")
else
print("Player is not whitelisted")
end
end)
Code 2 - does the same thing in 5 lines, but is much harder to read
local WhitelistedUsersIds = {1, 2, 45, 73, 97}
game:GetService("Players").PlayerAdded:Connect(function(Player: Player)
if table.find(WhitelistedUsersIds, Player.PlayerId) then print("Whitelisted Player Found") else print("Player is not whitelisted") end
end)
Clarity over concision makes your own projects easier to maintain as things scale up and easier for other developers to grasp what your code is doing on the first look versus having to re-reference the code over and over (ex: I had to read the code multiple times to figure out what variable t, i, w, and r meant - reading variable names captured in single letters versus just writing out random or tick [a separate discussion of whether these really need to be localized at all does exist]).
Just wanted to add that as a small note!
I definitely don’t suggest doing this. What this code does is rev up the processors as a yielding function. In other words, it does this:
--"Yield"
for i = 1, 50000 do
--fake "yielding" by doing something
end
--Resume
2 Likes
Don’t use this code.
This is literally wasting so much processing power that it slows down code execution.
This is completly false. A really fast loop should just run for x number of times then yield to the next execusion cycle. Someone can use the time library for a timekeeper. There is no reason to wait less than the events Roblox already gives you, and definitely no reason to do something that slows down your entire game.
2 Likes
Agreed,
That would be slowing down Computers since the said computers can barley process stuff that fast, You would pretty much be overwhelming the Computer with all the Data in a short Period of time,
Don’t get me wrong, they are fast, but not that fast,
For Example:
functions like print and math take time to process, this would just cause lag due to that time needed to process that information, and execute it.
Since it runs so fast, It will either freeze the Server (or client), or Lag the game
2 Likes
Yeah, it doesn’t even matter how fast the computer is: the faster the computer goes the more resources it takes to slow down the fast computer.
Try this code. Making 20 of loops with your function takes the game to 5 FPS. Running 20 loops with task.wait doesn’t even change the milliseconds per frame by 0.01.
local function stupidWait(TIME: number?)
local t = tick or os.clock
local i = t()
TIME = TIME or 0.01
local w = task.wait
local r = math.random or Random.new
while t() - i < TIME do
if r(1,100000) == 1 then w() end
end
return true
end
local runningLoops = 0
game:GetService("UserInputService").InputBegan:Connect(function(inputObject)
if inputObject.KeyCode == Enum.KeyCode.E and inputObject.UserInputState == Enum.UserInputState.Begin then
runningLoops += 1
print("Stupid loops running: "..runningLoops)
while true do
stupidWait(1)
end
end
end)
local runningLoops = 0
game:GetService("UserInputService").InputBegan:Connect(function(inputObject)
if inputObject.KeyCode == Enum.KeyCode.Q and inputObject.UserInputState == Enum.UserInputState.Begin then
runningLoops += 1
print("Less stupid loops running: "..runningLoops)
while true do
task.wait(1)
end
end
end)
Your code is over ten thousand times less efficient (not even an exaggeration). No one should ever use this code, and it shouldn’t be on the forums to trick and confuse people.
1 Like
I mean how fast it can process the information, having something faster will just lag or crash it,
true, but even if it has more rescources, its still likely to be effected
1 Like
If the computer is faster won’t it allow the loop to go even faster and use more resources, cause lag?
I’m pretty sure with the Computer itself, not really, but with the Game Client, yes, mainly due to its Engine and Capabilities.
I’ll never grasp why people try to use the same engine features, to make those engine features faster, or finding hacky methods at that, to try to mimick something being “faster”.
On that topic, I feel like even if this thing did what people would expect it too, it would have no purpose at the end of the day. I don’t see any real use case for this in a loop, especially any normal loop. Using task.wait() as is is already pretty fast and superseded the outdated wait() (much needed tbh)
I would just stick with the regular task.wait() method. It’s less code, easier to remember, and saves you time. Also with engine changes, you never know if this will forever be reliable.
Remaking engine features that are already good enough is probably not going to end well, as we can see here. I see that you did it for fun and all, but if that were the case, you probably wouldn’t want to post it here.
Good evening folks.
1 Like
Hello! I am just going to say now that this is not as fast as you claim it is. (Keep in mind the speed is also affected by your processor, and my processor is the i9-13900K, one of the fastest Intel CPUs on the market.)
After conducting some benchmarking I have found that the regular speed of this wait function on my processor is around ~.5249… between ~.6877… (Aproximations, not exact,) on a 0.1 wait. Even standard wait which has been proven to be the slowest built-in wait function currently, is ultimately faster than your custom function.
Original Benchmark:
Now I decided to make an attempt to fix/rewrite your script to be simpler, and at first I tried removing the math.random function in turn for just the w() function. This occasionally made it faster than task.wait, but this was in like every 1 and 10 benchmarks.
After that my friend suggested that I where to clean up the script and make it more simple and refined.
Refined Script:
local function twait(TIME: number?)
local i = tick()
local w = task.wait
while tick() - i < (TIME or 0.01) do
w()
end
return tick() - i
end
Final Benchmark:
This ended up being slightly faster than
task.wait(), and blazingly fast compared to wait().
Although Id still use task.wait() over this due to ease, but I hope this helps you, and I hope you learn something from this.
2 Likes