Expose entity locations

[Ralith]

Column-major serialization is desirable for compressibility and efficient processing. hecs provides APIs sufficient to allow column-major serialization of the entire world by walking its archetypes, but is less helpful when only a small subset of entities should be serialized at a time. This requirement arises e.g. in large streaming worlds such as hypermine, where entities will be serialized when their enclosing volume is unloaded to conserve memory.

I'm interested in feedback on the approach taken here, since it constrains future evolution somewhat. One less constraining (and less breaking) alternative would be to expose a fn get_archetype(&self, index: u32) -> &Archetype on World rather than exposing the entire slice, for example.

[adamreichold]

I'm interested in feedback on the approach taken here, since it constrains future evolution somewhat. One less constraining (and less breaking) alternative would be to expose a fn get_archetype(&self, index: u32) -> &Archetype on World rather than exposing the entire slice, for example.

I think exposing that entities are organized into archetypes is already done so that part (pub struct Location) does not really change anything. (I guess it would also be a different ECS if that ever changed, even if the API stayed the same.)

As for exposing the slice, I suspect that storing the archetypes in a slice will always remain the sweet spot for fast component access even if additional index structures are added on top. Maybe you could add some language as to how long the returned Location values are guaranteed to stay valid though, so that you could in principle reorganize the archetypes vector in any call that modifies the components.

[Ralith]

I think exposing that entities are organized into archetypes is already done so that part (pub struct Location) does not really change anything.

Yeah; only new leak there is that u32 is sufficient to identify one, but I think that's fine.

I suspect that storing the archetypes in a slice will always remain the sweet spot for fast component access even if additional index structures are added on top

Yeah, that makes sense. There is still the possibility of interposing some structure like slab that's morally a slice but which doesn't expose a &[T], though. We could always hack around this be reimplementing said structure ourselves, but maybe that's not the best use of maintenance budget? Or maybe I'm overthinking this.

[adamreichold]

Yeah, that makes sense. There is still the possibility of interposing some structure like slab that's morally a slice but which doesn't expose a &[T], though. We could always hack around this be reimplementing said structure ourselves, but maybe that's not the best use of maintenance budget? Or maybe I'm overthinking this.

I suspect that if you have that many archetypes that you want to slab-allocate them, you are probably better off with an ECS that is not archetype-based. :-)