You can write your topic however you want, but you need to answer these questions:
What do you want to achieve? Hi Im afraid that my game may has some memory leak, My game is poorly designed and uses alot of free model (Yes I removed the scripts), But something that is not free model is also scripted by me, Whose bad at Garbage collection
**What is the issue?**I think Memory Rise infinitely (Atleast on core memory, Lua heap does rise but it come back down again but its still a little higher than before), On both the client and the server, One loop i could think of is the pet loop which uses a while true do loop, but im not sure if this is even because of it, Because in other game such as adopt also but is much less steep and contain some flatline, And my game contain a 8000 by 8000 map which will need to be loaded all the time
What solutions have you tried so far? Yes disconnect function, But sometimes function cannot be disconnected such as player character added on the pet loop, And when player dies, I respawn their pet, I also wraped some code in
do end
to maybe make some varieble out of scope?
But im not sure how much this will help
Memory leaks can happen for many reasons but commonly happen due to poorly managed connections and instances that aren’t disconnected/destroyed when unneeded, generally due to oversights when implementing and using OOP or repeatedly creating connections (eg. while true do loops, creating connections inside of connections etc and never disconnecting), or even parenting many instances to nil and never destroying them. But really, it’s difficult to tell whether you have a memory leak unless you’re playing a game for some time and memory usage becomes very high without a reason. If you’re using object oriented programming in your scripts and these objects use userdatas (such as connections/signals/instances) and you aren’t properly disposing of them, it’s possible. But really, it’s hard to tell without examining your scripts. Also, wrapping your code in do-end blocks is good, it should discard any redundant references, however that being said, ensure you aren’t skipping over any connections that you need referenced, and that you aren’t losing reference to nil instances because they’ll always be in memory and will never be garbage collected unless destroyed.
You should read up on memory leaks and how to identify them, there are far more in-depth and well-written tutorials than what I’m giving you:
If you’re working with connections, I recommend looking into managing them. There are many solutions but the most “famous” one is the maid object by Quenty, it’s easily manageable and object oriented to make life even easier. Also, and I can’t express this enough, if you’re using bindable events, you should really switch to a custom signal class.
That’s not to say you do have a memory leak, an 8000x8000 map is also very large and can be expensive depending on how detailed it is which could be another reason you see an influx in memory, I recommend looking into solutions such as streaming enabled or a proximity-based selective replication system which you can create on your own or look at the ones created by the community.
--amogus
--- Manages the cleaning of events and other things.
-- Useful for encapsulating state and make deconstructors easy
--amogus
local Bob = {}
local stuff
function Bob.Clean(part)
print("Cleaned")
stuff = part
print(part)
do
part:Destroy()
end
--stuff.Parent = workspace
end
spawn(function()
wait(2)
print(stuff.BrickColor)
end)
return Bob
It still prints DarkMetallic Gray, Even if the baseplate is destroyed, And then I cloned the stuff and parent it to workspace and it works, So as long is a variable of any destroyed things is not nil, It still technically exist? And I also parented a kill script to it, And a texture and those are gone, So stuff is a reference to the baseplate?
This is intentional, the parent property is locked though, however its members (functions, properties and events) are still accessible until the next gc cycle happens again, once you lose reference to this part, it will be garbage collected. Attempting to change its parent property will also result in an error any time after its destroy function is called. Being able to clone it is intentional, since the clone function of the part is a member of the instance.
I’m not too sure how it works on the backend but from the Lua garbage collection documentation, it says Lua will only garbage collect things that it knows for sure are garbage- destroying the instance likely marks the part as garbage on the backend, hence why destroying it will not cause a memory leak. Destroying it also disconnects all of its connections so you don’t have to disconnect those if you can ascertain that the is being destroyed.
Yes, because the garbage collection doesn’t happen until the next garbage collection cycle happens which I believe is when the end of the scope is reached, eg. the end of a function, the end of a loop, or at the end of a do-end block and I believe when it isn’t referenced anymore.
Not sure what you mean. When you destroy an instance, all of that instance’s descendants are destroyed and parented to nil as well, so you don’t have to iterate through its descendants and destroy those as well.