Does Roblox automatically garbage collect Tween Constructors?

Throughout my career of programming on the ROBLOX platform, a few rumor are going around one being that Roblox does not garbage collect their tween constructors. Now there is no hard evidence to suggest this, so I’d like to ask if anyone has any form of evidence to go against or with this topic.

If you haven’t noticed, after creating a Tween Constructor, there is :Destroy() method, which actually works (Once the method is called, attempting to connect RBXSignals such as Completed will no longer function). Which is probably lead to this whole theory.

With this knowledge, it’d be helpful to the community to know whether or not we should be manually destroying out tweens like so;


local Animate = TweenService:Create(...)


Or if it’s completely unnecessary.


I mean, in my games I don’t clean up after myself and players don’t experience lag, so I suppose it does get gc’d

Could you provide more information regarding your situation? I believe it’d be helpful to us.

How long do the server usually stay up for?
Do server automatically shutdown?
What’s the max player cap?
How many concurrent players have you tested this with?

It’d be beneficial to understand the statistics of your game.

The servers were 10 people, I tested with 2 or 3 other people. The server did shut down when we were done (so that could be why), we did it maybe for 20 minutes or so

Fantastic, unfortunately based off these statistics we can’t really use it as hard evidence that the constructors to get GC’d.

Some memory leaks are minor and aren’t noticeable after a long duration of playtime (it also matters on player count and how you’re utilizing tweens and how often you do so).

We’re also un sure if you’re tweening on the Client (which you should be doing) or on the Server. If it’s on the client, the player can simply rejoin to clear that lag (the memory leak would be client sided).

Ideally, the best situation would to have a full server with a long play time and common use of tweens.


Once the tween has completed and you have no further references to it, it will be garbage collected.

So long as your variable is defined locally, you don’t need to destroy it manually.

If you did want to destroy it though, you’d want to wait for Tween.Completed to fire otherwise you destroy it instantly before it has chance to play.


Hey, that’s great to hear (I’ve been destroying it all manually just in case). But is there any form of evidence that we can dig up to that we can use when someone does disagree on it?

This started as a myth and lead to arguments everywhere I go, I’d appreciate if there is any form of evidence.

Logically, this would make sense considering Roblox is providing this tool for us developers who are too lazy to lerp (Internally the tween may be more optimized as well), it wouldn’t make sense to not let us know if it doesn’t get cleaned up and cause memory leaks.

1 Like

The evidence is just knowing how the garbage collection system works. Tweens are a type of Instance and are garbage collected the same as any other non-parented Instance.

If you have a reference to the tween, for example a variable in a scope such that there is code that depends on that variable that hasn’t concluded, then it won’t be gc’d, just like with any Instance.

Likewise, when there are no further references, it will be gc’d. In your case, the local variable reference is cleared when the code block finishes, and therefore when the tween has completed playing, there aren’t any references to it remaining.

I don’t know how it’s supposedly leading to arguments.

As a side note, calling Destroy won’t directly gc it anyway, and won’t guarantee it will be gc’d. It just sets parent to nil (already is), disconnects connections on it, and locks property changes. In the same way a reference to a Part or other instance will prevent it being gc’d after Destroy, the same applies here, as it’s the same method.


So just to clarify;

local Part ="Part")

Is not a memory leak.


Correct. Because the do block ends and the reference is released, so the unparented unreferenced part will then be garbage collected.