Scripting Helpers is winding down operations and is now read-only. More info→
Ad
Log in to vote
1

Which costs more performace: "listeners" or "endless-loops" ?

Asked by
AlexTheCreator 461 Moderation Voter
4 years ago

Hello all,

This is a bit of a weird one (kinda abstract?) I don't think it really matters in dy-to-day use but I'm just curious. On a recent thread three approaches were suggested (see below).

My question is, focusing on how the script is listening to game and acting on the code (regardless of the usefulness/efficiency of the code inside being run) which method causes the least performance issues? (is it better to have listeners for many events, one event, or use infinit loops to determine status?)

1) Updating playercount and acting via PlayerAdded and PlayerRemoved:

view source
01local Players = game:GetService("Players")
02local door = script.parent
03 
04local function checkPlayers() --check if the door should be open and act upon it
05    if #Players:GetPlayers() >= 2 and door.CanCollide == true then --if there are more than two players and the door isnt open, open the door
06        wait(40)
07        door.CanCollide = false
08        door.Transparency = 1
09    elseif #Players:GetPlayers() < 2 and door.CanCollide == false then --if there arent enough players and the door is open, close the door
10        door.CanCollide = true
11        door.Transparency = 0
12    end
13end
14 
15Players.PlayerAdded:Connect(checkPlayers) --everytime a player joins...
16Players.PlayerRemoving:Connect(checkPlayers) --everytime a player leaves...

2) Updating playercount and acting via Heartbeat:

[ADAPTED: the original post has been edited to exemplify the question]

view source
01game:GetService("RunService").Heartbeat:Connect(function()
02 
03    if #game.Players:GetChildren() >=2 then
04    script.Parent.Transparency = 1
05        script.Parent.CanCollide = false
06    elseif #game.Players:GetChildren() <2 then
07        script.Parent.Transparency = 0
08        script.Parent.CanCollide = true
09    end
10 
11end)

3) updating playercount and acting via an Infinite loop:

view source
01local Players = game:GetService("Players")
02local door = script.Parent
03 
04while true do
05    if #Players:GetPlayers() == 2 then
06        door.CanCollide = false
07        door.Transparency = 1
08    end
09    wait(.01)
10end

I hope you can make sense of my question. Thank you for taking time to read this!

3 answers

Log in to vote
2
Answered by
VerdommeMan 1479 Moderation Voter
4 years ago
Edited 4 years ago

easily the first one which only fires when a player joins or leaves

second one fires 60 times a second

and last one fires 37 times a second (minimum wait is 0.027)

0
and the fact that there are more things listening "from" script 1 doesn't make a difference? Now that I think about it, I suppose the question is also how do listeners work... are they themselves hidden loops waiting for something to happen? AlexTheCreator 461 — 4y
0
no, you give them a function and when an action happens for instance here when a player joins a game, they fire the function for you VerdommeMan 1479 — 4y
0
I know this sounds dumb but...how does it know when a player joins? In terms of LUA as a language how do events fire...from my perspective it looks like the function is doing "while true do repeating wait() until action" ?? ohh, or is it more like someone transmitting an FM signal (action) through the air (game) and listeners are passively hearing the noise because they are tuned into the station? AlexTheCreator 461 — 4y
0
I feel like that though process kinda answered itself at the end there but thought id post it for others thinking the same thing :) AlexTheCreator 461 — 4y
View all comments (3 more)
0
no, in case of playeradded what might happen behind the scenes (i dont know this at all but its so you might understand how events work) the client sents a request to the server (he clients wants to join the server), server checks if he is allowed to join (server not full etc,) connection establihsed, now it fires playeradded and it creates the character for that player which fires characteradded VerdommeMan 1479 — 4y
0
so it never really waits, its just responds to actions, like when player joins it calls the function that fires the event, like look into bindeable events where you can create custom events and you ll see you dont need to wait at all, you make it fire the function after an action happens VerdommeMan 1479 — 4y
0
so for example what roblox might do for characteradded is, https://pastebin.com/pDpNfbTu this is just an example its not real its so that you can understand that evenst just get called after an action happens VerdommeMan 1479 — 4y
Ad
Log in to vote
0
Answered by
megukoo 877 Moderation Voter
4 years ago

PlayerAdded and PlayerRemoved are the superior options here.

Work is only done when a player is added or removed, instead of endlessly checking the state of the players, even if it hasn't changed. By using those events, you're updating it whenever it has to and not all the time.

To expand onto your comment, I don't really know how things work internally, but I'm assuming a signal is sent from the C side to the Lua side, along with any info it may have (the player that joined/left, etc.)

Log in to vote
0
Answered by
iOwn_You 543 Moderation Voter
4 years ago

You should always use events instead of endless loops, endless loops are one of the biggest factors for performance issues, you should always use events and listeners when you have the option to. Reason being is that roblox writes their code for their events and functions in LuaC/C which is much faster and more efficient than RBXLua.

At the thread you linked the advice given using loops was pretty terrible and you should never do that when you have functions like PlayerAdded and PlayerRemoving.

Answer this question