This topic was automatically opened after 10 minutes.
What does proto
refer to in the Object Tags
view?
Also is the size in the EDIT: Nevermind I’m a fool, ignore this part.Object Classes
view accurate? Why are EnumItems so large?
Also, is there a way to use this to locate RBXScriptConnections that have been orphaned? How would we go about doing that if so?
Thanks either way. This will make optimization work a lot more data-driven. Any chances of us getting this supported for plugins in the future? We’ve been trying to improve the performance of the Rojo plugin so it’d be helpful.
Entirely new territory to micro-optimize and annoy everyone working on the project w/ me! Amazing!
srs: Thank you so much for this! This seriously helps optimization, and it’s going to reveal so much behavior to me that I didn’t know before. Great feature
Thanks for making this, this should be a really useful tool for keeping an eye on optimization of scripts. Is it possible to see exactly what the signal connections are to better manage them?
This is awesome! having such an accurate tool for finding unparented instances is highly beneficial for everyone.
However, I can’t help but wonder looking at this UI - are there any plans to make the UI itself more readable? A color scheme with different colors for each category/datatype would make it a lot easier to read, as it’s a bit hard to do so for me currently; which applies to most of the console really. Class icons for instances would be a great help, too!
Is there a feature that sorts the elements by their Count, Memory usage, etc? I think this new feature will be useful in debugging memory leaks
‘proto’ refers to the object representing the function’s code and associated data.
Having a lot of memory taken by ‘proto’ can mean that there is simply too much code or static lookup tables in the experience.
In some cases where code itself is created on the fly (like sending ModuleScripts to the Client) it may increase over time.
What exactly is an orphaned script connection?
Just to clarify, functions referenced by connections are stored in ‘registry’ root by the engine.
While internal function result is a simple versioned table, making it public requires fixing the format.
It should be possible after a few months of getting experience with what it should contain.
Excellent job, well done becoming more like VS and that’s only a good thing
Agreed, I have hope that the entire developer console will be getting a new coat of paint in the near future. Unfortunately, like with everything else, that new coat might be too buggy for real world use until months or a year after launch.
Thank you, as a programmer, I designed it myself!
There is an internal project to revamp many of the Developer Console tabs (like the dreaded Memory) and add even more new tools, but I don’t have a timeline for that.
As an example, if I make a connection like this:
game.Players.PlayerAdded:Connect(function(player)
print("wow a player joined cool")
end)
there isn’t a reference to it, so there’s no way to ever disconnect it. This is generally a bad thing, but there’s not really a way to track those down right now.
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.