It seems like we're misunderstanding each other. Your objects being a `ref object` is exactly what you want, and the code I shared should do exactly the thing you're after. If I understand you correctly.
But lets walk through this. You have 10000 objects which are not trivially small (say somewhere above 30 bytes big). You want to be able to look these objects up with the O(1) access that a table grants you. You don't want to store them more than once in memory, and instead always pass around their address. A few things to note right of the bat: * Your table size will increase with how many elements you but in a table, doesn't matter how big or small the elements are, the size will increase. How much it increases is however a matter of the size of the objects. The size of your keys will also matter for how much space the table will consume. For a `Table[string, MyObj]` where `MyObj = ref object` the table really only stores a reference to the string, the hash of the string, and the reference to the underlying object of `MyObj` for each element. Tables, through their design, also need to allocate more room than strictly required to hold N elements. * Your objects are already `ref object` which means that they are already only created once and passed around by reference. Reference = pointer = address for the most part. * You still need to store the actual object somewhere. With `ref object` they will be allocated on the heap when you create them, with normal `object` they will typically be allocated on the stack or inside a data structure. So to summarize, your table will require some space, otherwise it wouldn't hold any information. Your objects, when declared as `ref object` will only have one copy in memory, and when passing the object around Nim actually passes around the reference instead of the object. As long as your object is a `ref object` you don't need to worry about this, put them in a Table like I showed you, it won't be super huge.