How to improve performance in entity relation scenario?

[piratf]

Background

I want to create a world in C++ with many cells, each with its own actors.
Different cells in the actual scene may calculate independently. Here we directly traversed all to observe performance overhead.
I guess I didn't find the correct usage, so come to ask.

I'm using entity relations like this:

// Add a new actor to cell
world.entity().set<EcsActor>({}).add<EcsRelationBelongsToCell>(cell_entity);

then save the query in each cell:

cell.actors_query = world.query_builder<EcsActor>().with<EcsRelationBelongsToCell>(cell_entity).build();

In the update process, I reuse the query to loop on all actors in each cell:

cell.actors_query.each([&counter](EcsActor &actor) {
  actor.is_active = !actor.is_active;
  ++counter.calc_actors;
});

I used std::vector to write the same logic for comparison.
All the demo code can be found here: https://github.com/piratf/flecs-demo-01

Performance Data

Running /tmp/flecs-demo-01/cmake-build-release/src/world_traverse_benchmark
Run on (16 X 2595.12 MHz CPU s)CPU Caches:                                                                                                                                                                                             
  L1 Data 32 KiB (x8)                                                                                                                                                                                   
  L1 Instruction 32 KiB (x8)                                                                                                                                                                            
  L2 Unified 4096 KiB (x8)                                                                                                                                                                              
  L3 Unified 16384 KiB (x2)                                                                                                                                                                             
Load Average: 9.97, 8.20, 6.42                                                                                                                                                                          
-------------------------------------------------------------------                                                                                                                                     
Benchmark                         Time             CPU   Iterations                                                                                                                                     
-------------------------------------------------------------------                                                                                                                                     
// cell number growths
EcsWorldProcess/20/500        19036 ns        19031 ns        28880                                                                                                                                     
EcsWorldProcess/200/500      311845 ns       311610 ns         3206                                                                                                                                     
EcsWorldProcess/2000/500    7665538 ns      7664249 ns           77                                                                                                                                     
StdWorldProcess/20/500         9659 ns         9658 ns        72175                                                                                                                                     
StdWorldProcess/200/500       97578 ns        97568 ns         7189                                                                                                                                     
StdWorldProcess/2000/500    1008097 ns      1007957 ns          702                                                                                                                                     
// actor number in each cell growths
EcsWorldProcess/200/50        68129 ns        68116 ns        10631                                                                                                                                     
EcsWorldProcess/200/500      206119 ns       206050 ns         3392                                                                                                                                     
EcsWorldProcess/200/5000    6716895 ns      6714882 ns           75                                                                                                                                     
StdWorldProcess/200/50        11095 ns        11093 ns        61633                                                                                                                                     
StdWorldProcess/200/500      101401 ns       101385 ns         6378                                                                                                                                     
StdWorldProcess/200/5000    1186562 ns      1186384 ns          592                                                                                                                                   
                                                                                                                                                                                                        
Process finished with exit code 0 

It seems that my implementation via flecs is much slower than traversing the vector directly, decreasing more dramatically as the number of cells grows (maybe the number of queries grows).

I have these questions:

• Is there a way to better leverage the capabilities of flecs in this scenario?
• Building query costs much. If I need to add more complicated grouping relationships in the future, it's going to cost more here. Is there another way to write it to reduce the cost of this?
• World destruction costs much when the cell number grows large, Is there a way to further reduce?

Profile Result

Here is the profile data:
ecs_world.init.pdf
ecs_world.update.pdf
ecs_world.quit.pdf
std_world.init.pdf
std_world.update.pdf
std_world.quit.pdf

[piratf]

Flecs version: Release v3.2.0, compiled from source code with the project.
I'm using the C++ API
Compiler: g++ (GCC) 10.2.0
CMake version: 3.25.2

[SanderMertens]

Take a look at query groups: https://github.com/SanderMertens/flecs/blob/master/examples/cpp/queries/group_iter/src/main.cpp

They'll let you create a single query that can be "grouped by" cell. You can then iterate the query for a specific cell, which should be a lot more efficient than creating lots of different queries.

[piratf]

Just found that you wrote exactly this case in the comments. I missed that part. I'm sorry.

[piratf]

Thank you for your guidance! I removed all the query build processes, and change the system like below:

world.system<EcsActor>().group_by<EcsRelationBelongsToCell>().kind(flecs::OnUpdate).iter([](flecs::iter& it, EcsActor *actors) {
  for (auto i : it) {
    actors[i].is_active = !actors[i].is_active;
  }
});

The new demo code was been pushed to the feat/group_by branch.

Benchmark output:

Running /tmp/flecs-demo-01/cmake-build-release/src/world_traverse_benchmark
Run on (16 X 2595.12 MHz CPU s)CPU Caches:                                                                                                                                                                                             
  L1 Data 32 KiB (x8)                                                                                                                                                                                   
  L1 Instruction 32 KiB (x8)                                                                                                                                                                            
  L2 Unified 4096 KiB (x8)                                                                                                                                                                              
  L3 Unified 16384 KiB (x2)                                                                                                                                                                             
Load Average: 10.06, 8.09, 7.05                                                                                                                                                                         
---------------------------------------------------------------------------------------------------                                                                                                     
Benchmark                                         Time             CPU   Iterations UserCounters...                                                                                                     
---------------------------------------------------------------------------------------------------                                                                                                     
EcsWorldFixture/EcsWorldProcess/20/500        19594 ns        19586 ns        35941 Per Loop=10k Total Calc Actors=470.52M                                                                              
EcsWorldFixture/EcsWorldProcess/200/500      198384 ns       198356 ns         2879 Per Loop=100k Total Calc Actors=592.8M                                                                              
EcsWorldFixture/EcsWorldProcess/2000/500    6154764 ns      6153838 ns          112 Per Loop=1000k Total Calc Actors=123M                                                                               
StdWorldFixture/StdWorldProcess/20/500        11845 ns        11844 ns        57530 Per Loop=10k Total Calc Actors=686.41M                                                                              
StdWorldFixture/StdWorldProcess/200/500      121867 ns       121834 ns         5877 Per Loop=100k Total Calc Actors=698.8M                                                                              
StdWorldFixture/StdWorldProcess/2000/500    1321061 ns      1320763 ns          556 Per Loop=1000k Total Calc Actors=667M                                                                               
EcsWorldFixture/EcsWorldProcess/200/50        40338 ns        40332 ns        17972 Per Loop=10k Total Calc Actors=290.83M                                                                              
EcsWorldFixture/EcsWorldProcess/200/500      169768 ns       169742 ns         4260 Per Loop=100k Total Calc Actors=537.1M                                                                              
EcsWorldFixture/EcsWorldProcess/200/5000    5511075 ns      5510569 ns          126 Per Loop=1000k Total Calc Actors=137M                                                                               
StdWorldFixture/StdWorldProcess/200/50        10126 ns        10125 ns        70448 Per Loop=10k Total Calc Actors=815.59M                                                                              
StdWorldFixture/StdWorldProcess/200/500      122284 ns       122263 ns         5873 Per Loop=100k Total Calc Actors=698.4M                                                                              
StdWorldFixture/StdWorldProcess/200/5000    1422366 ns      1422121 ns          492 Per Loop=1000k Total Calc Actors=603M                                                                               
                                                                                                                                                                                                        
Process finished with exit code 0

Here is the profile result:
std_world.init.pdf
ecs_world.update.pdf
std_world.quit.pdf
ecs_world.init.pdf
std_world.update.pdf
ecs_world.quit.pdf

I have these questions:

• As the number of cells increases, the performance decreases is still obviously. Are there any other improvements that could be made to the demo code?
• How to create a system like the above that can also accept a singleton input?

About using a singleton component, I tried to write it this way, but it will output a lot of groups with only one actor inside. Maybe I missed something here.
Is there any performance differences or tendency between getting mutable component in each iteration or adding them in the system declaration?

[piratf]

One more question here: Is there any other example of a customized group_by_relation function?
I tried searching here, It all looks like the same.
And I just found that the group by feature could work even without the function. Is there any special scenario that needs to customize this function?

[SanderMertens]

Are there any other improvements that could be made to the demo code?

Try upgrading to 3.2.1, it can improve query performance in some cases by 20-40% :)

How to create a system like the above that can also accept a singleton input?

Because you're using the iter function to iterate the query, adding a singleton will iterate entities one by one. The reason for this is query instancing. To fix this, you can either replace iter with each (easiest) or add .instanced() to the system builder (check the docs/examples to see how to iterate an instanced query).

And I just found that the group by feature could work even without the function

Yeah I need to update the examples to remove the custom group_by function since it's not really necessary, as the default group_by function does exactly what you need here (group by relationship).

Is there any other example of a customized group_by_relation function?

This is the builtin group function that's used by the cascade feature: https://github.com/SanderMertens/flecs/blob/master/src/query.c#L765