Put asset_events behind a run condition

[james7132]

Objective

Scheduling low cost systems has significant overhead due to task pool contention and the extra machinery to schedule and run them. Following the example of #7728, asset_events is good example of this kind of system, where there is no work to be done when there are no queued asset events.

Solution

Put a run condition on it that checks if there are any queued events.

Performance

Tested against many_foxes, we can see a slight improvement in the total time spent in UpdateAssets. Also noted much less volatility due to not being at the whim of the OS thread scheduler.

[BorisBoutillier]

Do we need to do a thorough pass on all bevy systems to check their internal complexity and if there is a pertinent run condition to add, or is this still a compromise and always need to be checked against a benchmark ?

[james7132]

Do we need to do a thorough pass on all bevy systems to check their internal complexity and if there is a pertinent run condition to add, or is this still a compromise and always need to be checked against a benchmark ?

The main goal here is performance so I'd always measure the results to ensure we don't have any regressions. Run conditions are always done on a single thread and block scheduling new system tasks, so there is a tradeoff to be made here when we're talking a large number of systems.

[hymm]

Is the Tracy with the system level spans disabled? That could significantly change the results.

[james7132]

No. I didn't disable system or run condition spans for either run. I'll go ahead and disable both and see how it goes.

[alice-i-cecile]

I'm curious about those perf results, but won't block on them :)

[james7132]

Is the Tracy with the system level spans disabled? That could significantly change the results.

This is the comparison for the AssetEvents schedule with the system spans commented out. Disabling the system spans shows an even bigger improvement. I disabled it both on this PR and main.

A significant portion of that last ~40us is likely attributable to executor/thread wake-up overhead, which should be addressed by #11801.

[hymm]

Thanks for redoing the benches.