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.
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.
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.
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:
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() ?
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.
Exactly. Using RunService in those cases is a bad practice. It is recommended to use RunService only if absolutely necessary.
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.
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.
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.