I’ve recently been replacing wait() in the form of doing something along the lines of:
if tick() - LastUse > TimeBetweenUses then
LastUse = tick()
--code
end
Recently I’ve been working on something that runs this if statement in excess. I’m having to do some rewrites of the code for efficiency and I remember reading in a script a while back that a method like this is intensive.
My question is how intensive is tick(), and should I rewrite the code to use it less(not very possible) or simply go back to a wait() method instead?
I don’t understand why you’re using some weird workaround method instead of using something like wait, spawn, or delay…?
Can’t say how performance heavy your code is as you don’t actually provide any information about when, in what context, or how often you run the statement. I recommended using one of the three aforementioned methods if possible. Seems like a micro-optimization.
I run the code in Hearbeat that loops a table, and each table element has it’s own “LastRun” variable set to it. The if statement could be running anywhere from 5 to 1000 times every time the Heartbeat event loops. My goal is simply to find the most optimized way to do this particular thing, so there isn’t a need for the rest of the code.
If I was to use wait(), it would have to set each element of the table to its own loop, which just seems a bit excessive to me.
I can look into delay() and spawn() and see if it increases speed, but again I’m just looking for the most efficient method overall.
You should not use spawn, delay and sometimes wait.
Using tick shouldn’t be intensive at all it just returns a float and with modern day machinery it’s more than enough to process what you are attempting.
Using a tick Debounce is arguable more accurate and better practice in certain cases which you do not want to have unnecessary yielding and create absurd amounts of new threads.
(It’s also less punishable when mistakes are made)
Not really sure what you’re trying to do, but it seems unnecessary.
Why not just do something like this?
function useAbility()
if canUseAbility then
canUseAbility = false
-- Ability code
wait(ABILITY_TIME)
canUseAbility = true
end
end
Do you need to update the ability at certain cooldown times or something? Just use the TweenService for aesthetics. Running something on heartbeat like this versus just using wait() is probably a lot more intensive, albeit probably not by much.
Use coroutines instead then, I was giving a comparison to OP’s method.
Not really sure how that avoiding wait() article is relevant at all. I’m assuming ability cooldowns aren’t at 1/20th of a second which is what that article talks about.
I’d argue running something on heartbeat is not “better practice” than using a simple wait(). The debate here would be if OP needs to avoid yielding and is creating new threads using coroutines, which I don’t think would be a problem if the code is ran on an input event.
The concept is that I shoot a gun, bullet hits area, area then explodes(made up of voxels), and voxels that were exploded are added to a table, which is then looped through to move them in a curved motion.
The method would require multiple threads with anything other than the tick() method. Everything in the table that the Heartbeat loops through needs to be gotten to during that loop. If I have a wait(), it holds up the rest of the elements in the table. Obviously delay() and spawn() could have potential uses, but after reading the previous articles linked they are out of the question.
On the note of how you responded to @RuizuKun_Dev, would a coroutine be better than my current method, or is the tick() method better? Based on the response, it seems like tick() is the best, and if no argument can be made for coroutine it seems that is the answer.
Definitely don’t create new threads (coroutines) on Heartbeat, that’d be much worse than using tick() on heartbeat. tick isn’t very intensive, just getting a value.
It sounds like you’re essentially simulating projectiles. Definitely use heartbeat and don’t create new threads for this.
Heartbeat returns the delta time between “heartbeats”, so you don’t even have to use tick:
local t = 0 -- total time since start
rs.Heartbeat:Connect(function(dt)
-- dt stands for delta time since last updated
t = t + dt
-- code with whatever you need here, might not even have to use t
end)
I didn’t even realize heartbeat returned that, thanks for pointing it out. I appreciate @RuizuKun_Dev and your help on this, thanks for your guys time!
