For example my script generates a coroutine every second.
while true do -- server script
wait(1)
local BoolValue = Instance.new("BoolValue", workspace)
BoolValue.Changed:Connect(function() -- this is the coroutine am talking about.
-- something
end)
BoolValue:Destroy() -- what happened to the listener?
end
In a minute, my script will have generated and destroyed about 60 listeners. I won’t notice any performance issues.
In… lets say 100 hours, my script will have generated and destroyed 360,000 listeners. Are they still alive anywhere in my computer after the BoolValue being listedened to was destroyed? Will I notice any performance issues?
Not that I tested it, but my pc AINT handling a third of a million asynchronously.
Thanks for reading
I will be replying late I’m going to sleep
When you call :Destroy on any instance, it sets the parent to nil, locks the parent and disconnects all connections. The last part is important.
No, they are cleared from memory and won’t hang around. When they don’t, it is often referred to as a memory leak and negatively impacts performance.
No, tho this isn’t a heavily optimized approach ofc, it won’t cause any performance since the garbage collector will free up the allocated memory for the BoolValue.
Just out of curiosity why would you want to constantly listen for an event just to destroy it? I get that this is an extreme example (I’m hoping you aren’t actually using a loop to constantly listen for a .Changed event lol). Because the whole purpose of events is quite literally to avoid constantly having to check if said value has been altered with loops. So wouldn’t this be counterproductive? Wouldn’t it just be simpler for you to listen to the event once or only connect/disconnect when needed?
an example hehe. its not exactly every 1 second. Like about 20 listereners every 10 or so minutes. In my game, players have tools they can drop and pick up on their free will. I force the server generate a proxmimity prompt openting the pick up tool option.
I know i should be making the client generate them and build the listeners themselves-> fire the server if they picked up, but i already started with the server script and it would take too long to change.
You should just always have the proxmityPrompt exist in the tool. Just enable/disable depending on whether a player owns/has the current tool. That way the server just generates the events when the game first runs! But I get what you mean tho. You should try to make it client-sided like you said (for the option to pickup the tool, always do the main security checks on the server). Will give you more flexibility later on in development!
