Components as entities

[Trashtalk217]

Objective

There are two primary problems we currently have with resources-as-components (#19731) .

Performance regression #23039

In order to get access to a resource entity, you usually need to go through two lookups: TypeId -> ComponentId -> Entity. The ComponentId -> Entity lookup can potentially be removed, speeding up resource lookup.

World Asset Serialization (previously in bevy_scene) #22968

Currently, one big downside of resources-as-components is that any components on resource entities aren't serialized. This forms a barrier for implementing required components for resources. Implementing this correctly is tricky. One of the problems we run into is that IsResource(ComponentId) cannot be directly copied over because ComponentIds are not consistent between worlds.

Solution

We change ComponentId(usize) into ComponentId(Entity) and use the EntityAllocator to create ComponentIds. Next, we store all resources on the ComponentId entity. This makes the ComponentId -> Entity lookup a no-op. And we can also use the MapEntities machinery to serialize and deserialize worlds.

Future Work

In the future, we can look at adding parts of ComponentInfo as a component to the component entities. That sounds confusing, because it is. This would improve the introspection ability of the ECS (being able to query for metadata about the components). This, however, requires quite a bit of weird bootstrapping, which I don't know how to do and is not necessary for this PR.

Testing

This is principally a performance PR, and while I will be doing some benchmarking myself, I don't have the hardware. So I'll be asking someone to give it a once-over when it's ready.

[urben1680]

so far so simple!

[SkiFire13]

In order to get access to a resource entity, you usually need to go through two lookups: TypeId -> ComponentId -> Entity. The ComponentId -> Entity lookup can potentially be removed, speeding up resource lookup.

On the other hand note that you have introduced a HashMap lookup into every ComponentId -> ComponentInfo path! This happens for example when calling hooks, which is arguably pretty common too.

Sidenote: do we have a benchmark for hooks to measure this?

Currently, one big downside of resources-as-components is that any components on resource entities aren't serialized. This forms a barrier for implementing required components for resources. Implementing this correctly is tricky. One of the problems we run into is that IsResource(ComponentId) cannot be directly copied over because ComponentIds are not consistent between worlds.

I'm not sure how this PR solves the issue. You'll still have the issue that the EntityId in the new world needs to match the ComponentId of the resource.

[SkiFire13]

We'll likely want to benchmark this.

[Victoronz]

Given that ComponentId is now a newtype over Entity it should now be able to utilize EntityEquivalent and the EntitySet infrastructure to offset some of the performance cost.

[SpecificProtagonist]

The instance of the component on its own id would be the one accessed by Res/get_resource/… regardless of there being instances on other entities. Iirc some place used to do that to allow you to provide both a global default and an entity-specific override.

That doesn't make resources more powerful, but by making them less special it could simplify our code.

[Trashtalk217]

I've added the benchmarks from #24058 and got the following results.

If resources are stored with Table (compared to main).

ecs::resources::get     time:   [6.9392 ns 6.9575 ns 6.9770 ns]
                        change: [−2.3300% −1.6645% −0.9613%] (p = 0.00 < 0.05)

ecs::resources::get_mut time:   [11.583 ns 11.613 ns 11.646 ns]
                        change: [−6.5349% −5.6392% −4.9772%] (p = 0.00 < 0.05)

ecs::resources::insert_remove
                        time:   [105.28 ns 105.50 ns 105.76 ns]
                        change: [−5.9114% −1.9506% +2.5391%] (p = 0.40 > 0.05)

If resources are stored with SparseSet (compared to main).

ecs::resources::get     time:   [6.1838 ns 6.2066 ns 6.2309 ns]
                        change: [−12.963% −12.303% −11.496%] (p = 0.00 < 0.05)

ecs::resources::get_mut time:   [7.2262 ns 7.2469 ns 7.2692 ns]
                        change: [−41.461% −40.792% −39.973%] (p = 0.00 < 0.05)

ecs::resources::insert_remove
                        time:   [88.820 ns 89.095 ns 89.403 ns]
                        change: [−20.547% −17.317% −14.328%] (p = 0.00 < 0.05)

[SpecificProtagonist]

Resources being components inserted on themselves should also solve the following behavior currently in main:

#[derive(Resource)]
struct A;
#[derive(Resource)]
struct B;
let mut world = World::new();
world.spawn((A, B));
// This is fine
assert!(world.get_resource::<A>().is_some());
// This panics
assert!(world.get_resource::<B>().is_some());

[SkiFire13]

FYI I just noticed that two important uses are in Table and SparseSets. Especially the Table one is called multiple times when iterating a Query (the SparseSets one only once) and once for every Query::get (!)

Given this I would definitely include the results of query iteration and get benchmarks.

[alice-i-cecile]

I've spent a great deal of time giving this preliminary consideration, and I don't think this is the direction I want to take Bevy. The conceptual model is too unclear, the edge cases are extremely nasty (complexity and impact), and the degree of coupling between component metadata storage and other elements of the ECS is too high. I'm closing this out to avoid further effort being wasted here.

The underlying problems and motivating features (perf regressions, serialization issues, fancier relations) are still desirable, but I would like to fully exhaust alternate paths before reopening this design.

[Trashtalk217]

For my part, I've always struggled with the critiques this PR attracted. If the conceptual model is unclear: In what way? The edge cases are nasty: What specific edge cases? Complexity, too, is in the eye of the beholder. To really nail down which approach is more complex, we'd have to look at the eventual API surface and how intuitive the behaviour ends up being.

I think I've not been specific enough when proposing this change. I've felt that this was a 'sure thing' and neglected going into enough detail. Still, a lot of the critique has felt quite high-level and abstract, which was frustrating.

I hope that in one/two years, when the ECS has more features that can take the edge of the edgecases (non-removable components, entity ranges, removing registered components from the world, and probably some I'm missing), a better programmer/communicator can take another attempt.

In the meantime, I hope I haven't poisoned the well of discussion by being this persistent /annoying.