Archetypes

Soooo lets talk about archetypes.

If i am correct, archetypes offer a higher iteration speed. This is because entities with the same components are stored in one big array. Which means that the iteration over them can be loaded more efficient into the cpu. So iteration is a lot more cache friendly, which results in a performance boost.

So we should probably look into this. I assume that this wouldnt even require a major rework. Only the component storage would need some optimization.

I recently looked into those articles. Theory behind archetypes Unitys ECS C# Archetype ECS

So a very quick and dirty first draft of a archetype based component storage would look like this…

    // Just stores an array of components, any smarter solution ? 
    public unsafe class ComponentPool {

        public void* components;  // We tightly pack all archetype components behind each other e.g. Player, Transform, Player, Transform
        public int length;

        // Unsafe operations to add, set or get certain components from the array
    }
    
    // An archetype, basically all entities with the same components. 
    public class Archetype {

        // An id which represents a bunch of types, somehow generated from a Type[] array basically
        public int id;
        public Type[] types;

        // The entities within that archetype
        public Entity[] entities;
        public ComponentPool components; 
        public int size;
    }

A few problems remain…

• Adding/Removing components is getting costly ( Can be solved by just disabling then )
• Iteration over a subset is a bit more difficult i guess ( Not sure if its slower or faster, but more complicated )

You know the source code of default.ECS way better than i do, would you mean that such an archetype based architecture would improve the speed and how hard would it be to change the underlaying component storage ?

[Doraku]

It is starting to look great, when using Single or Shared mode for component, the overhead is ~x2 compared to current implementation, all api should stay intact. In archetype mode the overhead is ~x4 when using the old Get<T> api for convenience but the new api gives x3 more performance compared to current implementation!

A lot of work still remains, the next big question is what to do with MultiMap systems, is it possible to do something so they can benefit from archetypes? A new api should be also created for entities to batch modifications together so the archetype is only changed once even if we do multiple Set/Remove to limit copy.

[nrader95]

Interface IToggleable which can be implemented by components and queries check that one during iteration

This would be causing boxing if your component is a struct and you work with it after casting your type to interface.