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.
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.