Bevy ECS: Parallelization Limits When Systems Share Mutable Component Access

Context

Bevy's ECS executes systems in parallel by default, but any two systems that request mutable access to the same component type are forced into sequential execution unless explicit ordering constraints (.before() or .after()) are declared. This behavior is documented in the Schedule and System execution model.

Goal

Determine the practical threshold at which the scheduler's conservative conflict detection begins to materially reduce frame-time parallelism in a system set that processes high entity counts (10,000+ entities) with overlapping component queries.

Constraints and Uncertainty

The scheduler does not currently expose a diagnostic API that reports how many systems were serialized due to inferred conflicts versus explicit ordering. Profiling tools show total frame time but do not attribute serialization overhead to specific component-access patterns. Version 0.14's SystemSet hierarchy and SystemConfigs modifiers are assumed.

Questions

1. Is there a supported method to query the scheduler for the conflict graph it builds at startup?
2. Can Query<&mut T, With> and Query<&mut T, With> run in parallel when A and B are disjoint archetypes, or does the type-level conflict check ignore filters?
3. What is the recommended pattern for intentionally splitting a mutable component into fine-grained sub-components to recover parallelism without introducing sync points?