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:

local Players = game:GetService("Players")
local door = script.parent

local function checkPlayers() --check if the door should be open and act upon it
    if #Players:GetPlayers() >= 2 and door.CanCollide == true then --if there are more than two players and the door isnt open, open the door
        wait(40) 
        door.CanCollide = false
        door.Transparency = 1
    elseif #Players:GetPlayers() < 2 and door.CanCollide == false then --if there arent enough players and the door is open, close the door
        door.CanCollide = true
        door.Transparency = 0
    end
end

Players.PlayerAdded:Connect(checkPlayers) --everytime a player joins...
Players.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]

game:GetService("RunService").Heartbeat:Connect(function()

    if #game.Players:GetChildren() >=2 then
    script.Parent.Transparency = 1
        script.Parent.CanCollide = false
    elseif #game.Players:GetChildren() <2 then
        script.Parent.Transparency = 0
        script.Parent.CanCollide = true
    end

end)

3) updating playercount and acting via an Infinite loop:

local Players = game:GetService("Players")
local door = script.Parent

while true do
    if #Players:GetPlayers() == 2 then
        door.CanCollide = false
        door.Transparency = 1
    end
    wait(.01)
end

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