ecs: switch from ArrayList per-table-per-component-set -> single-[]u8-per-table #338

Merged

emidoots merged 3 commits from sg/ecs into main

2022-06-10 20:24:27 +00:00

emidoots commented

2022-06-10 19:52:27 +00:00

(Migrated from github.com)

This switches our ECS over to manually managed memory (one []u8 per archetype table, with multiple column arrays packed into it - dealing with padding/alignment ourselves) rather than the prior 1 ArrayList(Component) per component in an archetype table.

There is no change in the user-facing API yet, the goal of this change is just to get to manually managed memory. There are some things that are not entirely optimal because of this that I will explore in future PRs.

This idea was discussed in depth in #ecs:matrix.org (thanks Levy!) Notable advantages from my POV:

This means we don't need an ErasedComponentStorage interface, which is nice.
It means component storage does not have to have a Zig type. It could e.g. in theory enable the ECS to be usable from other languages (C, WebAssembly plugins, etc.) with component types defined in those languages in the future.
It reduces some overhead ArrayList has: slice ptr+len+capacity integers per component array per table
It guarantees component arrays are contiguous memory, rather than relying on the allocator to hopefully provide that (may not hold true in multi-threaded large-allocation situations.)
It means we could easily optimize for tables that have very few components by allocating exact memory for them (could've done this with ArrayList too, but now it's more likely the allocation are larger and thus more reusable by future archetype tables.) This could be quite important because one can imagine ending up with many small archetype tables.

Overall seems like the right thing to do, so we're doing it.

By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

This switches our ECS over to manually managed memory (one `[]u8` per archetype table, with multiple column arrays packed into it - dealing with padding/alignment ourselves) rather than the prior 1 `ArrayList(Component)` per component in an archetype table. There is no change in the user-facing API yet, the goal of this change is just to get to manually managed memory. There are some things that are not entirely optimal because of this that I will explore in future PRs. This idea was discussed in depth in [#ecs:matrix.org](https://matrix.to/#/#ecs:matrix.org) (thanks Levy!) Notable advantages from my POV: 1. This means we don't need an `ErasedComponentStorage` interface, which is nice. 2. It means component storage does not have to have a Zig type. It could e.g. in theory enable the ECS to be usable from other languages (C, WebAssembly plugins, etc.) with component types defined in those languages in the future. 3. It reduces some overhead `ArrayList` has: slice ptr+len+capacity integers per component array per table 4. It guarantees component arrays are contiguous memory, rather than relying on the allocator to hopefully provide that (may not hold true in multi-threaded large-allocation situations.) 5. It means we could easily optimize for tables that have very few components by allocating exact memory for them (could've done this with `ArrayList` too, but now it's more likely the allocation are larger and thus more reusable by future archetype tables.) This could be quite important because one can imagine ending up with many small archetype tables. Overall seems like the right thing to do, so we're doing it. - [x] By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.