Sword Rewards System - How can I make this more efficient?

Help and Feedback Code Review
11

ok a few things I would like to mention about that wait function

  1. This is not your wait function. I’m the one that showed you this as a better alternative for that custom wait that polls. (Don’t take this as an attack I’m just saying).

  2. I wouldn’t recommend using this function in most scenarios as a complete substitute to yield your code instead of the default rblx “wait(n)” for the following reasons.

2A. There still comes the creation costs of implementing and destroying bindables which ruins the purpose of a customWait. A customWait is supposed to be accurate. Lets say you have to constantly call your customWait every 0.08 seconds. Imagine creating a bindable and connection every 0.08 seconds. The customWait that polls is technically more accurate than this anyways.

-- I did not make this function :/\
local RunService = game:GetService("RunService")

local function customWait(yield : number) --> probably place it in rep storage in a module so both the server and client can use this function
      local timePassed : number = 0

      while true do
          timePassed += RunService.Heartbeat:Wait()
          if (timePassed >= yield) then break end 
      end
end

customWait(5)

This wait function is infact more precise than the customWait made with bindables which gives this function that doesn’t use bindables more purpose.

Disclaimer: Do not use this function that doesn’t use bindables either. It ends up flooding the task scheduler with instructions each time you call RunService.Heartbeat:Wait() since this function supports polling. And polling is not good practice.

Polling is bad practice XD – by Kampfkarren
^^ Here is an article that explains why polling is not recommended in production code.

2B. “Whats wrong with flooding the task scheduler :/”

In this scenario, when you keep calling your customWait function that polls, instructions appended into the task scheduler’s primary queue, end up not being ran on time (delayed). You are using heartbeat which is good since it has the lowest priority in the task scheduler but more important functions could be using Heartbeat as well, which makes this custom wait impractical to use in game dev.

Proof that yielding adds instructions into the task scheduler:
Proof yielding adds instructions into the task scheduler XD – by Thedagz

2C. Creating a heartbeat connection each time you want to yield with your bindable customWait function doesn’t seem very practical either. Each time you create a connection, that connection runs on it’s own thread. Threads cost resources.
3. In conclusion, using the default rblx “wait(n)” would more practical to use (and if you want to yield for a frame use “runserviceHeartbeat:Wait()” to yield instead of “wait()”). An accurate custom wait would be useful in situations that require more precise accuracy. I’ve already mentioned a few reasons why that it shouldn’t be spammed.

Proof of a polling wait actually affecting in an actual game with 8K + players:
Proof of a polling wait function having negative effects XD – From one of the programmers of Tower Defense Simulator

1 Like