-
-
Notifications
You must be signed in to change notification settings - Fork 96
Svelto.ECS memory layout
One datastructure to rule them all, we could say. Entities are stored in Svelto.ECS using just one unique (but complex) data structure. The entity components are stored according their types and no boxing/allocation will ever happen. When EntityStructs are used, the data is laid out sequentially in arrays for maximum performance, however the use of groups will dictate the splitting of these arrays.
For a long explanation, check this: https://github.com/sebas77/Svelto.ECS/issues/36
short one:
Entity components are stored sequentially regardless the entity types that generate them. When an entity component array is returned through the entitiesDB query methods, it will contain all the entity components of all the entities that generate that specific component. However this is true as long as they belong to the same group. Grouping can be then exploited to split how entity components are laid out in memory. This becomes very handy when you want to write engines that need to iterate over different entity components using the same array index.
If you have an Entity Descriptor X generating the components (entity views) A and B and an Entity Descriptor Y generating the components B and C, you cannot iterate the arrays of the components A and B with the same index, as they will have different length. However as long as X and Y are generated in two different groups, then you can rest assured that the components of A and B of X are just the ones generated by X
The entitiesDB function that returns directly an array also returns the count of the valid entities inside the array. Returning an array is essential for performance purposes when struct are used, but the array length won't coincide with the count of the entities inside it. This is due to optimizations related to the internal Svelto.ECS code.
Related articles: