Chained EntityCommands create useless temporary archetypes

[alice-i-cecile]

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

When calling EntityCommands::insert (or remove, or the bundle equivalents) repeatedly within a single system, all intermediate archetypes are constructed.

Suppose we have an entity with the component A, and call .insert(B) and .insert(C). Despite only caring about enities that have the component sets (archetypes) {A} and {A, B, C}, the archetype {A, B} is also constructed.

This has both immediate performance costs, and reduces general program performance as these empty archetypes continue to exist.

What solution would you like?

Automatically batch all component-modifying methods on EntityCommands into a single modify_bundle EntityCommand for each entity before processing them.

What alternative(s) have you considered?

Users can acheive this effect by manually grouping these calls, but this is limited to pure insertion or pure removal EntityCommands, non-obvious and can lead to less clear code.

We could do even smarter batching strategies, e.g generating spawn_batch calls, but that is a) much harder and b) less immediately important.

Additional context

This is essential to ensuring that #1481 is both usable and maintains correctness at all times, otherwise these temporary archetypes are constructed and can fail the assertions generated.

[Nilirad]

This will become a bug once #5121 gets merged. Should it be tagged as such?

[alice-i-cecile]

It may even block #5121, as it's a serious hinderance to the usability.

[BoxyUwU]

I don't think that this should block #5121/Archetype invariants, removing "useless" archetype moves should be an optimization not fundamental to the usability of archetype invariants. It seems reasonable that archetype invariants cannot be checked after every command since then .insert(A).insert(B) may crash during the "intermediate" step.

An alternative solution might be to add stuff to the Command trait as to whether invariants have to hold before running the command?

[alice-i-cecile]

An alternative solution might be to add stuff to the Command trait as to whether invariants have to hold before running the command?

This seems like a sensible solution; I think we could do this to unblock the work there.