Bevy ECS Schedule and Change Detection Interoperability

Bevy utilizes a multi-threaded executor within its Schedule to parallelize systems based on component access locks. A core feature of this architecture is change detection, which allows systems to filter for entities that have been modified since the last run.

In scenarios involving massive entity counts where updates are infrequent, the overhead of tracking these changes across the system boundary may impact performance. There is uncertainty regarding whether the scheduler can bypass change detection checks entirely for specific system sets when no modifications are flagged globally.

Does the current Schedule implementation provide a mechanism to suppress change detection overhead for low-traffic workloads? Can a system be configured to skip its execution entirely if no entities within its query have been flagged as changed by previous systems in the same frame?