The largest improvement can be seen when adding/removing prefabs to an entity.
The use of getStore in systems has the nice side-effect of slightly improving the iteration speed due to caching the store.
Adding and removing components should also be slightly faster.
Things to consider:
Prefabs are no longer entities, so they are not registered and there is no need for a Prefab component. This is because now a prefab needs to be an object, to store its ancestors and children. Let me know if it breaks some use case.
Prefab removal is still an open topic. As of now (and I think next as well) we just remove the IsA(Prefab) relation. No auto-removal of derived prefabs, no auto-removal of prefab components.
Tag components {} without using defineComponent work fine, but non-objects throw typescript errors. To use strings or numbers as components you need to call defineComponent(() => "string"). Again let me know if it breaks use cases.
The tests and the add-remove and n-body benches have been updated. The other benches are not.
Everything should work as presented in the proposal https://github.com/NateTheGreatt/bitECS/discussions/153.Performance:
getStore
in systems has the nice side-effect of slightly improving the iteration speed due to caching the store.Things to consider:
Prefabs are no longer entities, so they are not registered and there is no need for aPrefab
component. This is because now a prefab needs to be an object, to store its ancestors and children. Let me know if it breaks some use case.next
as well) we just remove theIsA(Prefab)
relation. No auto-removal of derived prefabs, no auto-removal of prefab components.{}
without usingdefineComponent
work fine, but non-objects throw typescript errors. To use strings or numbers as components you need to calldefineComponent(() => "string")
. Again let me know if it breaks use cases.add-remove
andn-body
benches have been updated. The other benches are not.