Destroying parts created using Instance.new() causes the UntrackedMemory to increase over time

[Scarious]

I was searching around the forums and came across a post which mentioned spikes in UntrackedMemory when deleting a massive amount of parts. After doing some tests and figuring out what happens when you do something, I have found that a spike in UntrackedMemory occurs 100% of the time when you delete a part which was created using Instance.new(). This spike is far more noticeable if you delete 500 parts which were created using this method in succession.

This bug happens in all live servers of a game which utilizes Instance.new() to create a part, and then later calls :Destroy() on that part, or use some other method to delete it such as :ClearAllChildren(). This does not, however, seem to occur in studio instances of a game, though that is just from my experience.

I don’t know when this bug started occurring, but I do know that it is occurring as of right now.

I would provide videos or screenshots, but it doesn’t seem necessary considering it would just be a video of a baseplate with a bunch of parts being deleted.

repro: Test Repro 2 - Roblox

Side note(s):

• From my experiments, I believe this occurs with models/etc created using :Clone(), but only if you modify the properties (including children) in some way. I cannot confirm whether or not this occurs if you do not modify the properties (including children), since I have had mixed results.

[Khanovich]

Just to confirm, once this hits around 800 MB it stops right?

Spawning 500 parts in a single space generates 500^2 collisions temporarily. This causes the physics on the server to allocate some buffers that don’t reduce in size because it assumes this game will need that much physics memory in the future.

[Scarious]

I can confirm that this stops at around 785MB → 815MB. After reaching ~800MB, I waited 5 minutes and the UntrackedMemory remained at ~800MB.

[Khanovich]

Basically, this wasn’t a bug, but @chefdeletat is going to still add a system to free this memory when not using it since your use-case seems legit. Also we will make sure it shows up in the physics category instead of “Untracked”. Thanks for the report!