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).
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!
‘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.
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?
(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)
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.
Yes, ‘proto’ is short for the ‘prototype’ of the function and function (or closure, not confusing at all) refers to an instantiation of that.
Often there is only one instantiation, but there could be many if it’s defined inside a loop or connected to multiple signals.
Documentation will have a small guide that should have been included in the announcement as well.
Maybe even attach a hint inside the table - original names were defined internally more than a decade ago.
Great! Now we Ui designers are awaiting a new user interface for the console. It would be a very nice addition and it would make my life debugging quality much better.
