entity_ref `get_component_with_type` is slow

[tower120]

What problem does this solve or what need does it fill?

I'm trying to get components data from EntityIds(Vec<Entity>) with world.get(entity).... I'm experience some "unexpected" performance drop (in compare to Vec<Rc>).

Looking at the code of World::get<T: Component>(&self, entity: Entity) ... there is so much indirection... Getting component index from hashmap, then bursting through 3 indirections to get component "Column", and one branch between storage type.

What solution would you like?

Is it possible to somehow .... prefetch/cache that archetype table_row/column?

That's just too much... Thats waaaay slower then just cache misses with Rc.

Additional context

I use Vec<Entity> not that often... But sometimes you just have to use it ....

[TheRawMeatball]

AFAIK, Query s do this sort of caching :)

[tower120]

@TheRawMeatball Nice! Now if only there where "queriable" collection of entities....

[tower120]

@TheRawMeatball Or you meant world.query(...).get(entity) ?

[TheRawMeatball]

The second, but not quite like that - you need to construct the query with the components you're interested in first, and store it alongside the list. It'll do some of those indirections at build time, and then you can use get to go fast :)

[tower120]

So... From system query it should already work?

// For example
fn my_system(
    datas: Query<(&Data)>
)
{
    for entity in entites{                  // entities = Vec<Entity>
        let data = datas.get(enity);
    }
}

[cart]

Looking up an Entity's component vs looking up a value in a Vec will never be "identical" because we will always need indirection to determine (1) whether or not the entity has that component and (2) where that component exists. Vec lookup is the "upper limit" that ECS impls strive for (but will never reach ... its a logical guarantee).

That being said it should still be "approximately" the same cost as Vec lookups if you cache things like TypeId -> dense_component_index lookups, which we already do for Queries. And iteration will be very close to Vec iteration because these lookup costs only need to happen once instead of per-entity.

So... From system query it should already work?

Yup QueryState, which is used by System Queries and returned by world.query(...) , already caches everything that it (reasonably) can.

[tower120]

But.... Looks like get_unchecked_manual called by query.get() reconstructs Fetch and Filter State on each call (I'm not sure which exact implementation is called, but looks like there is some branches in Fetch::init).
Clearly, there is no such overhead for iteration...

P.S. Is component pointers stable for alive entities?

[cart]

We don't reconstruct Fetch and Filter State in get_unchecked_manual. We pass the cached state into Fetch and Filter instances. Fetch:init does do the work of looking up pointers to storages, but this cannot be assumed to be stable. Any time a new component or entity is added (or removed), that could trigger a reallocation of the array, which would invalidate the pointer. Caching that pointer would be very unsafe.

[cart]

For a given world borrow and set of entity lookups using that borrow, we can assume it is stable because nothing can add/remove entities or components during that time. But we can't store that in QueryState, which exists outside of a given World borrow.

We might be able to cache the Fetch and Filter instances inside of System Queries though (because components cannot be added / removed in a way that invalidates these pointers when the system is running). I can't assert that is valid off the top of my head though.