Create a single-threaded stage type that immediately applies commands (and other buffers) after every system

[alice-i-cecile]

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

In some games (or other applications of bevy_ecs), system parallelization is not critical: the game may not be performance constrained, the work may be done entirely on non-send resources (such as for scripting language integrations), or better opportunities for parallelism may exist within the system.

In this case, a single-threaded, imperative system execution strategy is the natural solution, which is much simpler to write and reason about, and can eliminate the delay in command processing that can make prototyping frustrating.

EDIT: as discussed below, this should be a new abstraction, rather than a modification to existing single-threaded stages.

What solution would you like?

Create a new "immediate" stage type that applies buffers immediately after running each system. This may also require creating a corresponding executor to run it.

Use SystemState::new(world) and then SystemState::apply() to immediately flush all buffers after the system is run, removing the delay on commands.

Additional context

Workaround for #1613, but comes at the heavy cost of eliminating system parallelism.

#2381 provides similar functionality for specifying linear ordering of systems within parallel stages, but does not immediately apply buffers.

[alice-i-cecile]

This should be a relatively simple issue to tackle for anyone looking to get started with learning the ECS internals :)

The solution should be about two lines of code and the test will be easy to write too.

[TheRawMeatball]

While implementation would be simple, whether it's something we should do is a different question. Similar to how the stage's single or multi threadedness doesn't affect ordering, they shouldn't affect command application either IMO. We can build an alternative system scheduler that is explicitly designed for this, but I don't think retro-fitting the existing single_threaded executor to do this is the correct idea.

[alice-i-cecile]

Hmm. It's not at all clear when you would ever want to use the existing behavior over the proposed behavior though. It seems dramatically more convenient and it seems quite unlikely that you care enough about perf costs like the loss of hypothetical Command batching if you're using a single threaded executor.

[Ratysz]

Single-threaded executor exists to cover the case where you are using the normal parallel API, but don't have enough work to get enough multithreading gains to outweigh the multithreading overhead. It's explicitly meant to be a drop-in replacement with identical behavior; moreover, said behavior is actually encoded within SystemStage itself, with it not caring which sort of executor it's using. SystemStage::single_threaded() doesn't create a "single-threaded stage", it creates a stage and gives it the single-threaded executor.

If we do want an abstraction like this, it should be an entirely new and separate stage implementation.

[alice-i-cecile]

Alright, I can get behind that. Thanks for the explanation / argument from both of you. I'll modify the base issue to reflect the new direction, as I still think this is worth considering.

[TheRawMeatball]

Personally, I still don't think this is a necessarily good idea, especially with stageless still on the horizon. If the goal is to have instant-applying systems, exclusive system coercion + a better linear order specification API feels like the better call.

[alice-i-cecile]

Yeah, I'd be reluctant to immediately dive into this until we see what more scheduler reworking brings. I think the goal is valuable, but I'm not sure this is the way to get there.

[alice-i-cecile]

Closing this out in favor of broader designs in #2801.