This is really super freaking cool. Developers have been lacking specific memory diagnostic tools for years. One thing that I really like is how specific you guys are when it comes to defining terms and learning to how to understand these tools. Documentation for the Developer Console has been lacking, and so hopefully this doesn’t follow in those footsteps.
I really look forward to using this tool. Thank you to everyone who contributed to this.
Omg!!! My evening is decided. Been waiting ages for tools for this.
What is defined as “global” under memory categories. Is that just Roblox scripts running in the background? Considering it makes up a large amount of memory used, I think it’s pretty important.
This is much needed. Thank you! Now yall should increase server memory 
Cool to see more tools like this, but I dont know if Im understanding this correctly.
For instance, does THIS mean that there is a memory leak in my game that keeps references to a lot of players for no reason?
Its a lot higher for Players than anything else, and the memory size for my DataManager are higher than normal too.
And as others have pointed out, the whole dev console needs a redesign at this point. Ever since the additions of more tabs, its now collapsed into a dropdown by default, which isnt great.
EDIT: It IS a memory leak!
local function HandlePlayerConfig(player, playerConfig)
player.CharacterAdded:Connect(function()
-- stuff
end)
end
I should have just looked at the Unique References tab lol, was able to find it instantly from there. Literal lifesaver.
Yes, this is one of the most likely reasons.
Keeping a connection attached to the player properties/events can also cause this.
References to players in a case like this should be reported in the ‘Unique References’ tab. If not, such a big chunk of memory should be easy to find in the ‘Graph’.
Consider testing out the new Player and Character auto-destroy behavior: New Player and Character Destroy Behavior
Or try to clean up the references manually if that doesn’t help (maybe you have a table where all players are recorded forever).
I will refer to Dan’s answer from yesterday on this:
Finally! I just literally Finished coding for today and saw this Announcement, This will help a Lot in making a lesser Memory footprint Instead of just reading a script over and over again… Especilly to complex/large Script’s, For my current case it helps a lot with Hardware Emulation and Terrain Generation. Thanks!
Yeah I already saw, I appreciate it! Look forward to the future.
What about this memory leak?
Are these snapshots saved to file? It’d be nice to be able to compare snapshots by saving them as a json or something
‘global’ mainly refers to allocations made by Roblox engine itself for internal structures like storage for Luau->Engine instance links and thread tables.
Memory used by Roblox background scripts is not included in this tool at all (like CoreUI controls).
Public engine scripts injected to the experience like ‘CameraModule’ should be under the corresponding ‘CameraModule’ memory category.
No, there are no plans right now to save/load files from this tool.
In the future, if API is unlocked, custom plugins might implement this function.
Oh my god, amazing. I never thought this would happen, but here we are!
It’s great to see this finally added, I’ve already been able to put it to use & find a couple of memory leaks which I didn’t know about, however it’s pretty lacking in multiple regards.
The UI is pretty shocking & hard to follow. I don’t think this should’ve been shoehorned in to the existing developer console. There’s many open source heap dump visualisers that y’all could’ve taken some inspiration from such as YourKit, rather than this long, strangely formatted & confusing table approach.
I would regard it as a critical feature to be able to store & load snapshots, and as a result this would allow us to develop our own external tools to parse & visualise these snapshots in a nicer manner, or perhaps even link the snapshots in with our IDEs in some manner.
Regardless, I’m happy to have it now rather than not having it at all, I just wish the front end & UX was considered to a greater extent.
This is weird. It’s documented that when instances are destroyed, aka when a player leaves, all instance connections are destroyed, so why does this behavior occur?
So, with this can you give us an example if what a data leak would look like? Where tabs should we be looking at and which row and such? Thanks.
This is the update of all time guys
(okay but on a real note, this REALLY helps me make sure how performant each module/system is in a game, and which ones are potentially leaking memory)
Curious what the difference between proto and function is here considering they’re (mostly) the same thing, does function refer to spawned closures?
PLEASE I COULD DO SO MUCH FUN STUFF WITH THIS
This is what I always assumed as well, until that announcement about PlayerCharacterDestroyBehavior came out. It seems like this was never the case for Players, they just got parented to nil without getting destroyed, hence the memory leak I was experiencing. So if you DO want the player (and their character) to get actually destroyed, set PlayerCharacterDestroyBehavior in workspace to Enabled.