James Liu
James Liu
Reran benchmarks after these recent changes. The effects are even more pronounced. ``` group ecs-id-size-opt main ----- --------------- ---- add_remove_component/sparse_set 1.00 1190.4±94.82µs ? ?/sec 1.11 1326.2±83.48µs ? ?/sec add_remove_component/table 1.00...
> I had a slightly different idea on how to combine the task pools. I wanted to give tasks spawned on a scope the highest priority; give tasks spawned onto...
> isn't that a problem with this approach too. If a user starts too many blocking tasks the compute task pool won't have any threads to work with either. If...
This recent change should fix it, though it also doesn't allow for proper prioritization either. It's running the tasks from higher priority task groups, but sometimes it just sits idle....
Thanks to fixes from @hymm the thread utilization of the remaining threads has been fixed.  This PR should be ready for general review now.
The extra overhead is likely because we're currently using `tick` over `run`, which has additional initialization costs that are persisted inside `run`. We likely cannot address that, at least not...
As discussed on [Discord](https://discord.com/channels/691052431525675048/692572690833473578/978844818606268466), the performance overhead is likely coming from the fact that `executor.tick` and `executor.run` are using different queuing methods, and using `executor.run` in a chain results in...
The thread distribution definitely looks to be fixed. This does make it much more pressing that we make these pools global if it's this simple to disrupt the task distribution....
If this is the case, is this overhead just the result of higher contention due to increased thread count inside the executor itself? If that's the case, I don't think...