Trigger function each 5 minutes

[Dev_Peashie]

Heya! Thank you for reading.
Quick question, if I want to trigger a function each 5 minutes? Right now Im doing this (server sided):

local f
local function Chk(now)
	f = now + 300
	while true do
		if f < os.time() then
			SomeFunction()
			Chk(os.time())
			break
		end
		wait(5)
	end
end
Chk(os.time())

Whats the difference if I only do this?

local function chk()
   while true do
      SomeFunction()
      wait(300)
   end
end

Questions:
If I increase the wait(5) to idk wait(60) on the first example, what issues/something I can expect? if I decrease it to wait(1), what pros and cons do I get?

Suggestions on a better approach?

Thank you for your help :3

[dandcx]

I’m pretty sure most developers try to avoid wait() when they can.

This goes into a lot more detail why

Avoiding wait() and why

This is an adaptation of a Twitter thread I made a while ago. This is simply a better formatted and more fleshed out version. Let’s talk about wait(). Not wait(n) (although if you are using small n values to where it’d be barely distinguishable from wait(), you’re probably going to hit the same issues mentioned in this thread). We probably learned about wait() at first as the solution to “why are my infinite loops crashing me?”. It’s a super easy solution and it works! This starts a bad habit…

wait don’t mind me your using wait(n) not wait()
this might help but I think your code is fine

[Dev_Peashie]

Yup I know that post. Its related, but, its not exactly what Im asking for.
What would I use then? A RenderStep/Heartbeat to only check each 5 minutes?..
Wait() is a good approach if you dont need accuracy on the time measure. Dont think that wait() is evil or something.

[MysteriousVagabond]

@Dev_Peashie

local function chk()
   while true do
      SomeFunction()
      wait(300)
   end
end

This should cover what you need to do in most circumstances. Running a singular, long wait tends to be accurate enough for most applications. This will always be preferable over multiple short wait(n)s, since the execution of each yield will always be a few milliseconds longer than specified in the call, resulting in some desync over time.

Bear in mind that if SomeFunction() yields anywhere in its code, that will impact the overall cycle time. That can be circumvented by executing SomeFunction() on a different thread using either spawn() or any of the coroutine functions.

[luya_yobanka (lyo)]

Hi. There is no significant difference other than the level of granularity. Your first code is more granular and can do more things in the middle of the count, for example stop counting. Your second code does not allow that flexibility.

Many will opt to use a specialized implementation with RunService.Heartbeat instead of wait. But in my personal opinion that decision is made when you know that wait is the main cause of performance issues based on an analysis of the end game.

[Dev_Peashie]

I understand what u mean. Thank you so much for ur reply. About SomeFunction() its not yielding, and if it does yup, I will create a new thread for it.
Each wait() causes a little delay each time, so long waits theorically will cause less desync over time. Is that right? Valuable info, thank you c:

[Dev_Peashie]

Thank you so much for ur reply! c:
So no impact difference? And yup, I agree, the first one is more flexible.
About implement RunService with this. I have a huge doubt about RunService. Isnt bad to trigger a function 60 times per second, using statements to check if the SomeFunction() should run or not? Isnt worst than just using wait()?

Everytime I use RunService I think that the client, gets unnecesary calls (when the task is actually not very important about sync) Then I really dont understand why calling a function 60 times per second, causing the client to solve that math so many times per second. (assuming 60 fps) For some specific tasks yeah! the RunService is mandatory, but, for simple task its not better just use wait() ?

[luya_yobanka (lyo)]

@Dev_Peashie

So no impact difference?

the answer is no. Lua is an amazing language and the table indexing, function calls and their various statements are the most optimized things in the language and any delay caused by them is simply negligible. We are talking on the order of tens to a few hundred microseconds. Of course the sum of these can be significant in very long scripts or very intensive processing.

@Dev_Peashie

I have a huge doubt about RunService. Isnt bad to trigger a function 60 times per second, using statements to check if the SomeFunction() should run or not? Isnt worst than just using wait()?

Exactly. Using RunService in those cases is a bad practice. It is recommended to use RunService only if absolutely necessary.

@Dev_Peashie

Each wait() causes a little delay each time, so long waits theorically will cause less desync over time. Is that right?

No, it does not cause a little delay each time. The problem with wait is that it is scheduled in a second queue which by design has a minimum waiting time (that minimum time that the wait documentation says). This second queue has lower priority than the first one and therefore if there are too many tasks at a given time, some tasks in the second queue wait for the next step to be activated, and so on. That is why it is very important not to create too many threads. These could become congested and cause the second queue to be delayed.

[Dev_Peashie]

@luya_yobanka

That is why it is very important not to create too many threads. These could become congested and cause the second queue to be delayed.

Thank you so much @luya_yobanka, I gotta sit and think about the info you told me, I understand what u are saying, now I should think, thank you so much!

[MillaGamerF]

You are amazing. So I was studying the delay method of promises and discovered that it uses Heartbeat to generate delay, but in a special way. It uses linked lists to schedule different wait tasks for the same Heartbeat thread. so I decided to make my own implementation, but using array instead of linked lists. From what you say array indexing is quite efficient. But I was wondering if using a thread this way is really significant in performance.

[luya_yobanka (lyo)]

I am not so familiar with the promises but it is always better to use one thread than several. Anyway remember that RunService.Heartbeat is constantly active and having one or several practically doesn’t matter (have the same effect). Unfortunately there is no official documentation about it.