As a Roblox developer, it is currently impossible to view a list of instances that are parented to nil, but still have references attached to them. There should be a feature added to studio that allows developers to browse / view a list of instances that are currently parented to nil.
Having this functionality would make debugging my games a lot easier, since this would allow developers to see which instances are not being garbage-collected over a period of time. Game instances can often have unique names associated with them, making it fairly easy to see which game systems are leaking memory (e.g. “hey, the map from 2 rounds ago is still not destroyed”).
Bonus points : Allow us to manipulate these instances via normal code! E.g. being able to parent them to workspace to analyze them to figure out what code generated them.
I was able to find a memory leak in my game simply by comparing instance names between rounds! Notice the GUID that persists between rounds 2 and 3. That should have been garbage collected, but wasn’t! It’s a memory leak!
The only way of doing this currently is by utilizing external exploit tools (such as synapse) to hook into the client’s memory. This is obviously not an ideal way of debugging memory leaks!
Would absolutely agree with this feature request for the exact same reasoning.
In a similar line of thinking, having a way to see whatever specifically ties those instances to purgatory (e.g. connected events) would be the icing on top.
I don’t care how hacky or slow the implementation of this is, I need this for debugging purposes exclusively. I have a serverside memory leak I’ve been chasing for a very long time and there is no way for me to find it. It’s only noticeable after having hundreds of players join and leave my game, and I cannot just go around disabling core gameplay systems. If I had this I’d be able to see exactly what is left hanging around without requiring hundreds of players.
Glad to help with this. This is incredibly useful to have because there’s no way without synapse to see it. We shouldn’t have to rely on an external tool, let alone an exploit just to dig this up.
Tools like this are important to the process of debugging memory issues, which of right now isn’t ideal and would be to inspect your code, make a guess, and look at the memory usage numbers and graphs.
Security note (to the engineers): As of right now, a few security features on roblox relies on not being able to reference a specific instance, instead having the reference but not having write or read access permissions.
As an example I can think of, assuming plugins are nil parented, you do not want that pluginA finding pluginB's reference to call pluginB:SetSetting().
There is still a huge need for this! Tracing the root causes of memory leaks is still very tedious because we lack tooling (such as the ability to browse nil parented instances) to assist the trace.
Tracking instances outside of the hierarchy is not feasible in regular engine code most likely, but it would be amazing if we could enable some sort of tracking mode in Studio that will add the instance to some sort of weak pointer container when the parent is set to nil, or remove it from that container when it’s set non-null. Then Studio could enumerate that list in UI and show the contained instances to the user if they’re still alive.
nil space is an essential part of optimising your game because you need to see if Roblox is actually bothering to properly remove the instances, or if there’s fragments being left over. (trailing lua references or some dirty connection)
A way to navigate this wasteland of “dead” and “temporary” instances is necessary to properly optimise games, I’m not even asking for the ability to revive stuff in the wasteland, just to see whats in it.
Honestly, a full on memory inspector would be useful too but there be dragons with security and weak tables can suffice even if their performance is questionable
It is fundamentally impossible to control the parenting of every instance in the engine when they are destroyed/removed/out of scope because you do not control what happens to every instance. What you suggest is a great way to generate extra work and overhead for yourself with no benefit whatsoever, and create a lot of inconsistency.
I still dont get what the fundamental problem is here?
are you guys saying that using say :Destroy() on larger groups of instances doesnt remove them entirely and has the potential for memory problems…
Cos in my experience I found Roblox garbage disposal works like a garbage disposal in your sink, it can happily delete about 40-100 instances per tik and kinda jams up if you just to shove in too much…(with possible memory leak problems being here)…if you got huge amounts of stuff to delete i find it works better to create a delete queue and feed stuff in over time. Or even better just reuse all the instances for whatever the new thing is…
There are innumerable code patterns that generate instances that will never GC, in situations where you cannot just destroy them or infer when they will be destroyed. Not to mention, programmers make mistakes.
Instances cant be memory checked with the workflow I use in other places because of their funky GC behaviour when it comes to Lua.
Lua references can be tracked by seeing if a weak table drops it on a GC cycle, this cant be ensured with Instances because their Lua objects can get GC’d even if it wasn’t destroyed.
I just now thought that this could be part of the tooling such as the microprofiler, I think some use cases such as:
viewing in real time instances that are parented to nil in the explorer
having an API to get the instances from lua code
to be too hard to implement, but maybe having something like snapshots or recording similar to the way microprofiler works, would allow for offline processing without real time requirements.
I think if we could dump we could benefit from fine-grained details of memory usage such as instances, when and where it was allocated from what script for example. Actually my mind may just have related to this announcement
