ECS: Investigate memory overhead vs iteration performance

[christopher-buss]

Currently arrays have been largely pre-populated because this gives us noticable iteration speed ups. What has not been considered by this is the memory overhead of this. A tradeoff will always need to be made somewhere, but it would be good to get proper data to back this to ensure we're making the right one.

ROBLOX is supported on devices with a total of ~1GB ram (including OS overhead), so we want to make sure we're not blowing through this limitation.

[christopher-buss]

One thing another ECS does (Becsy) is offer different component storage stratergies. It is given to the developer to choose the storage method to tradeoff iteration vs memory. This could be a potential idea.

[RigidStudios]

Can this be done with a function pre-initialize, so we'd pass in the component and tell the world how much to allocate of each field for that component?

world.setComponentSize(Frozen, 100);

Default would then be set to 10, and if people know there's going to be a lot, they can set it to up to 3000 or something.

[RigidStudios]

We can also potentially leave it as an optional parameter?

Tina.createComponent(Schema, prealloc=100)

[christopher-buss]

The problem with this is at the moment ids are a direct access into the table to avoid needing to map ids from the entity id to their component storage location. This is one of the reasons we can currently get away with not needing function calls to update an entities data. Any abstractions over this approach will cost performance.