You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A container type that could both work as a packed array storing components and there entity id, or as a sparse array.
Motivation
This would allow for a more efficient memory management (thus should improve cache hit rate), as a sparse array becomes inefficient as the number of "holes" increases.
Having some hybrid containers would allow the container to switch between being a sparse array or a packed array "on the fly", depending on how full it is.
State of the art
At the moment, only sparse array are taken into consideration. However, they are inefficient to store tag components on few entities.
Drawbacks
An hybrid type would add come overhead, so thorough benchmarking would be needed.
Plus, we need to know when it becomes more efficient than a sparsely populated sparse array.
Rationale and alternatives
Another possible design would be to set upon registration to the registry the type of container we need for our component. This shift the responsibility on the user to know in advance how it's software will behave.
Not having some way to store barely used components in a special way could impact performances.
Why is this design the best in the space of possible designs?
What other designs have been considered and what is the rationale for not choosing them?
What is the impact of not doing this?
Minimal implementation
Some kind of custom container, that would switch between being packed or sparse depending on it's fullness.
The kind of storage should be perfectly transparent to the user.
The text was updated successfully, but these errors were encountered:
Hybrid Arrays
Summary
A container type that could both work as a packed array storing components and there entity id, or as a sparse array.
Motivation
This would allow for a more efficient memory management (thus should improve cache hit rate), as a sparse array becomes inefficient as the number of "holes" increases.
Having some hybrid containers would allow the container to switch between being a sparse array or a packed array "on the fly", depending on how full it is.
State of the art
At the moment, only sparse array are taken into consideration. However, they are inefficient to store tag components on few entities.
Drawbacks
An hybrid type would add come overhead, so thorough benchmarking would be needed.
Plus, we need to know when it becomes more efficient than a sparsely populated sparse array.
Rationale and alternatives
Another possible design would be to set upon registration to the registry the type of container we need for our component. This shift the responsibility on the user to know in advance how it's software will behave.
Not having some way to store barely used components in a special way could impact performances.
Minimal implementation
Some kind of custom container, that would switch between being packed or sparse depending on it's fullness.
The kind of storage should be perfectly transparent to the user.
The text was updated successfully, but these errors were encountered: