Changing parent of a model/part many times LEAKS memory and takes MORE time

  1. What do you want to achieve? Keep it simple and clear!
    I am working on a custom distance rendering system which hides parts/models by parenting them in ReplicatedStorage if they are not within the distance defined. I have a problem where the more a model/part gets its parent changed, the longer it takes it the next time to change its parent. Also, changing parents leak memory.

  2. What is the issue? Include screenshots / videos if possible!
    The issue is: the more you change the parent of a model/part, the longer it takes next time to change its parent and you get memory leaks.

Here’s a video of my memory usage just going up from simply changing the parent of a model constantly: RobloxStudioBeta_iWlDSh0MOt.mp4

Keep in mind this is just a classic baseplate with a simple script to constantly change the parent of a model.

  1. What solutions have you tried so far? Did you look for solutions on the Developer Hub?
    I created a simple place and put a script that parents a model in ReplicatedStorage and back to workspace after the FPS hits 59+ repeatedly and stops after 3 minutes has passed. As it keeps changing the parent of the model, the memory usage keeps going up high and it takes longer and longer to change the model’s parent.

To test this out on your own, you’ll need to place a model in workspace and call it “Model”. Next you’ll need a LocalScript to keep track of your FPS put under StarterPlayerScripts and another put under StarterCharacterScripts to change the parent of the model. You could also put a custom wait of your choice so it doesn’t do it instantly, but regardless, over time it’ll end up at the same result.

When line 20 gets executed ( model:Destroy() ), roblox will error saying: “Script timeout: exhausted allowed execution time” and the memory will spike by more than 2 times before it goes back to the same level it was before destroying the model. If you don’t destroy the model, then the memory levels never go back down but stays as high!

FPS LocalScript:

-- Services
local RunService = game:GetService("RunService")
-- Instances
local LocalPlayer = game.Players.LocalPlayer
-- Configs
-- Variables
local lastIteration = nil
local start = os.clock()
-- Tables
local frameUpdateTable = {}
-- Functions
local function HeartbeatUpdate()
	lastIteration = os.clock()
	for index = #frameUpdateTable, 1, -1 do
		frameUpdateTable[index + 1] = frameUpdateTable[index] >= lastIteration - 1 and frameUpdateTable[index] or nil

	frameUpdateTable[1] = lastIteration
		math.floor(os.clock() - start >= 1 and #frameUpdateTable or #frameUpdateTable / (os.clock() - start))
-- Running Functions

Second LocalScript for changing the parent of the model constantly:

-- Services
local ReplicatedStorage = game:GetService("ReplicatedStorage")
-- Instances
local LocalPlayer = game.Players.LocalPlayer
-- Configs
local MAX_TIME = 180
-- Variables
local model = game.Workspace.Model
-- Functions
local function Start()
	local initiatedTime = os.clock()
	local start
	while true do
		start = os.clock()
		model.Parent = ReplicatedStorage
		repeat task.wait()
		until LocalPlayer:GetAttribute("fps") >= 59
		model.Parent = game.Workspace
		if os.clock() - initiatedTime >= MAX_TIME then
-- Running Functions

The more an instance’s parent changes, in this case a model, the more memory is being used and it takes more computational power to make the change.

I’ve published the test place and tested it in Roblox directly and the problem did not seem to be as present.

However, on Roblox Studio, it’s very easily noticeable.

Here is the published place: Parenting Test - Bug - Roblox

And here is the roblox place file:
Parenting Test.rbxl (65.4 KB)


Following up! Is this issue still occurring ? @Arizyen

1 Like

Hi, it is still happening in the studio place, yes.

As you can see the memory usage keeps going up.


It seems to have been fixed, although it still happens but at a very unnoticeable level.

You can download the test place and run it to see for yourself.


I’m glad the issue has been fixed!

Thank you for the update! If you come across any other issues, feel free to send it our way!