Question about Tables and memory

[Guest9132342]

Say I have a table of players: {Player1, Player2, Player3}, this table will only store a refrence tot he already exsisting player class objects in game.Players.

So does that mean that this table will take around the same amoount of memory as a table that stores the players IDs: {Player_ID1, Player_ID2, Player_ID3}

[MineGameIdle (Lego_Boi)]

I believe it varies on the playerids?

[Wigglyaa]

I’m not sure how much memory would be allocated to store a reference (I assume this is a hexadecimal memory address? but I’m not sure), however, the UserId is a number type value which would be 64-bits.
The player object itself however, would be considerably more, so maintaining a strong reference after they’ve left the game would be more costly as it would be passed over for garbage collection.

[Guest9132342]

@Wigglyaa

The player object itself however, would be considerably more, so maintaining a strong reference after they’ve left the game would be more costly as it would be passed over for garbage collection.

To my understanding of the garbage collection process, if you still have a refrence to the player when they leave the game then the player object will just remain in memory until all refrenecs are gone

[fellow_meerkat]

@Guest9132342

To my understanding of the garbage collection process, if you still have a refrence to the player when they leave the game then the player object will just remain in memory until all refrenecs are gone

An instance is eventually going to be garbage collected once there are no strong references and the instance is disconnected from the data model. If an instance is present in workspace and all references in our code are removed, it will still remain intact where it is.

The case of player and character instances is more delicate. They are not destroyed automatically unless PlayerCharacterDestroyBehavior is manually enabled, and neither were they in the past before this property existed. During the course of the next year, the opt-in behaviour is going to become default (applies to server!). More in the announcement post.

---

Back to the main question.

---

Your thinking sounds about right and @Wigglyaa answered you already, so take this as a short extension of their reply.

UserIds are labeled as int64, though Luau does not distinguish between ints and floats, treating them all as number type, which is double, that is, (double precision) 64-bit floating point.

LuaVM accesses instances via userdata, and a variable essentially points to it. Tables, instances, functions… these are all objects passed by reference, whereas, for example, numbers and booleans are not. Those hex numbers Wigglyaa mentioned are related to the VM’s special registry to keep track of all instances for identification purposes. It does not pose as a strong reference to stop collection.

Simple showcase

local original = {"something"}
local reference = original

table.remove(original, 1)
print(reference[1]) --> {}

original = 5
reference = original

original += 5
print(reference) --> 5

So yes, variable references to instances are comparatively very small in size. The implementation details for the registry and exact sizes are hidden somewhere in the source code.