Bevy ECS: Table vs Sparse Set Storage for Medium-Frequency Components

Component Storage Interoperability

Bevy Engine utilizes two primary storage strategies for components: Table storage for dense data and Sparse Set storage for sparse data. While Table storage offers superior cache locality for frequent iterations, Sparse Sets provide flexibility for components added or removed often.

A design challenge arises when components exhibit medium-frequency usage patterns, where the performance benefits of dense packing are offset by the overhead of moving data during entity mutations. There is currently no automated mechanism to transition a component's storage type based on runtime usage metrics.

What are the performance implications of choosing Sparse Set storage over Table storage for components that are present on roughly 30-60% of entities? Is there a documented threshold where the overhead of Sparse Set lookups outweighs the cost of Table memory shifts during frequent component removals?