Add an optional bitmap-indexed query/filter path for high-churn ECS workloads

[AGeorgy]

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

Bevy ECS is very fast for dense archetype/table iteration, but some workloads are less ideal for the current model:

• many marker/tag components
• frequent add/remove of temporary state components
• queries with many With<T> / Without<T> filters
• large simulations where most entities should be skipped quickly

In these cases, filtering cost and archetype churn can become significant. It would be useful to investigate whether Bevy ECS could benefit from an optional bitmap index for component presence, inspired by the approach used in StaticEcs.

What solution would you like?

Add an optional bitmap-indexed query/filter path to Bevy ECS.

The idea is that component presence could be represented as bitmaps, allowing queries like:

Query<Entity, (With<A>, With<B>, Without<C>)>

to be evaluated conceptually as:

bitmap(A) & bitmap(B) & !bitmap(C)

This should not replace Bevy’s current archetype/table storage. Instead, it could be an internal optimization for specific cases, such as marker-heavy or high-churn components.

Ideally, this would require little or no new query syntax. Existing queries could automatically use bitmap filtering when it is beneficial.

What alternative(s) have you considered?

• Use Bevy’s existing archetype/table model.
• Use sparse-set components for high-churn markers.
• Store flags inside larger components instead of adding/removing marker components.
• Maintain manual side indexes in user code.
• Use a fully bitmap-based ECS architecture.

These workarounds can help, but they either reduce ECS ergonomics, require manual synchronization, or do not directly address filter-heavy query performance.

Additional context

This idea is inspired by the Bitmap Index / hierarchical inverted bitmap approach implemented in StaticEcs:

https://github.com/Felid-Force-Studios/StaticEcs

The request is not to replace Bevy ECS with StaticEcs’ architecture, but to explore whether a similar bitmap-based filtering mechanism could be useful as an optional optimization inside Bevy ECS.

[AGeorgy]

English digest / paraphrased translation of the Habr article:
“StaticECS — Bitmap Entity Component System” by FFS_Studios
Source: https://habr.com/ru/articles/1027940/

⚠️ This is not a full verbatim translation. It is a faithful English technical digest that follows the article’s structure and meaning while avoiding wholesale reproduction of the copyrighted text.
Images are embedded from the original Habr storage URLs and remain attributed to the original article/author.

---

1. ECS in brief

An Entity Component System separates data and behavior:

• Entity — a numeric identifier with no data by itself.
• Component — a data structure attached to an entity, such as Position, Health, or Velocity.
• System — logic that iterates over entities matching a required set of components.

The key performance question is: how quickly can the framework find all entities that have a given component combination, for example Position + Velocity, especially when there are hundreds of thousands of entities?

---

2. Existing ECS storage approaches

2.1 Archetypes

Examples mentioned in the article: Unity DOTS, Flecs, Bevy, Arch.

The archetype model stores entities with the same component set together. Each unique component combination forms an archetype/table. Inside a table, component arrays are contiguous, which is excellent for cache-friendly iteration.

The cost is migration. When a component is added or removed, the entity must move from one archetype table to another. That requires copying data, patching holes, and updating indexes. In large projects, unique component combinations can create many small archetypes, which queries must scan.

2.2 Sparse sets

Examples mentioned in the article: EnTT, LeoECS.

Sparse-set ECS stores each component type independently. A component pool usually contains:

• a dense array of component data,
• a sparse mapping from entity ID to dense index.

Adding or removing a component does not require moving the entity between tables. However, multi-component queries often iterate through the smallest pool and then check other component pools entity by entity. This can cause random memory access and poor cache prefetching.

---

3. Limits of those approaches

Archetype-style ECS

Main limitations:

• adding/removing components causes entity migration;
• every unique component combination may become a new table;
• grouping is based on component signature, not necessarily on game/application intent;
• discriminator tags can multiply archetype count.

Sparse-set ECS

Main limitations:

• multi-component queries often require per-entity checks;
• component existence checks may jump through memory unpredictably;
• entity-level bitmasks still require checking each entity one by one;
• sparse arrays may cost memory over the full entity ID range;
• there is usually no built-in logical or spatial grouping at the storage level.

---

4. Alternative: bitmap index

The article’s core idea comes from database indexing.

Instead of storing an index as a number per entity, each component type owns a bitmap of entities that have that component.

For example:

• Position has a bitmap of all entities with Position;
• Velocity has a bitmap of all entities with Velocity;
• All<Position, Velocity> becomes a bitwise AND of two bitmaps.

The result is another bitmap: all matching entities.

The important distinction from ordinary sparse-set ECS with entity bitmasks is the direction of the index:

Model	Query behavior
Entity stores component mask	Check each entity’s mask individually
Component stores entity bitmap	Combine whole bitmaps in batches

A 64-bit CPU word can represent 64 entities, so one bitwise operation can process 64 candidates at once.

---

5. Hierarchical bitmap

A flat bitmap is not always enough. If the bitmap is large, scanning it linearly still costs work.

StaticECS introduces a hierarchy. A higher-level bitmap summarizes lower-level blocks. In the article’s model:

• a block represents 64 entities;
• a chunk summarizes many blocks;
• one chunk covers 4096 entities.

Each component pool stores high-level heuristic masks per chunk:

• not-empty block mask — at least one entity in the block has the component;
• full block mask — all 64 entities in the block have the component.

This lets queries skip large regions before scanning exact entity bits.

Example idea from the article:

• Archetype ECS must find matching archetypes and iterate each table.
• Sparse-set ECS iterates a pool and checks other pools entity by entity.
• Bitmap ECS can first test chunks and blocks using a small number of bitwise operations, then only scan the blocks that might contain matches.

---

6. Memory model

StaticECS stores data in flat arrays. Logically, memory is organized through four levels:

1. Cluster
2. Chunk
3. Segment
4. Block

Inside each segment, entity metadata and each component pool are stored separately.

A naive flat-array approach has two problems:

• holes — some entities have a component while nearby entities do not;
• interleaving — entities of different logical categories can be mixed together, preventing dense iteration over the data you care about.

---

7. Entity types: the first storage dimension

StaticECS introduces entity type as a storage axis.

An entity type is a logical category such as:

• unit,
• bullet,
• effect,
• particle,
• UI element.

Unlike archetypes, an entity type is not defined by the current component set. Two entities of the same type can have different components but remain in the same type-specific storage region.

Difference from archetypes

In archetype ECS, adding a component changes the entity’s archetype and moves its data.

In StaticECS, adding/removing/replacing a component does not move the entity. The type answers “what kind of thing is this?”, not “which exact component set does it currently have?”

Hole filling strategy

When an entity is destroyed, its slot becomes a hole. StaticECS prefers to fill holes with newly created entities of the same type, gradually restoring dense regions.

Stable index

Because the entity’s position does not change while it is alive, the index becomes stable. The article highlights several consequences:

• easier serialization without remapping;
• direct relationships/references between entities;
• network synchronization by stable entity identifier;
• streaming and unloading clusters without affecting other clusters;
• deterministic iteration order when the same sequence of operations is repeated.

The tradeoff: entity types require intentional design. They are powerful, but the developer must choose meaningful categories.

---

8. Clusters: the second storage dimension

A cluster is an isolated memory area that groups entities by arbitrary logic:

• level,
• region,
• team,
• scene,
• network room,
• active/sleeping simulation area.

Together, entity types and clusters form two-dimensional partitioning:

Entity Type × Cluster

A query restricted to a cluster can skip other clusters completely. This is useful for streaming, LOD, level/zone partitioning, and multiplayer rooms.

The article contrasts this with other ECS approaches:

• Unity DOTS shared components can approximate grouping, but each unique combination can create more archetypes.
• Flecs can encode relationships/tags, but they are not the same as a first-class storage-level cluster.
• EnTT does not provide spatial/logical storage partitioning in this form.

---

9. Performance characteristics

Add/remove: O(1)

Adding or removing a component does not move entity data. It updates the presence bit.

Iteration: group filtering

Queries are filtered in groups and at multiple hierarchy levels. Entire regions can be skipped before exact iteration begins.

Batch operations

Bulk operations over query results — add a component, destroy entities, toggle a tag — work with the same blocks used by iteration.

Memory placement

Components are stored densely inside segments. Types and clusters do not require extra entity indexes or mapping tables; the core storage is component data plus presence bitmaps.

---

10. Comparison of approaches

---

11. Benchmark results

The article presents integration and micro-benchmarks comparing StaticECS with several .NET ECS frameworks.

Integration benchmark: 16,000 entities

The benchmark covers a more game-like workload: entity creation, component add/remove, iteration, and destruction in one run.

Micro-benchmarks: 100,000 entities, 13 frameworks

The article also shows isolated operation benchmarks.

The article’s benchmark claim is that StaticECS consistently ranks highly while using significantly less memory in the shown tests.

Benchmark sources referenced by the article:

• Integration benchmark: https://github.com/Felid-Force-Studios/ecs-benchmark-runner-dotnet
• Micro-benchmarks: https://gist.github.com/

---

12. Main framework features

Beyond the bitmap storage architecture, the article describes StaticECS as a full ECS framework.

Why “Static”?

The framework stores world state in static fields of parameterized classes. Each unique world type gets isolated storage, for example a game world and a UI world.

The article argues that C# generics and static generic types allow direct access without virtual dispatch or interface overhead in hot paths.

Main claimed benefits:

• no virtual calls in hot loops;
• expressive type-safe API without performance loss;
• multiple isolated worlds;
• declarative query system.

Entity system

Entities have stable IDs with version counters, so stale references can be detected. Entity status also accounts for streaming states such as active, destroyed, or temporarily unloaded.

Components and tags

Components are ordinary data structs. Lifecycle hooks are optional.

Tags are data-less markers represented as bits in bitmaps. Filtering by tag is therefore another bitmap operation.

Multicomponents

Multicomponents allow variable-length collections per entity, useful for:

• buffs,
• inventory slots,
• waypoints,
• child elements.

The article emphasizes segment-level allocation and serialization benefits.

Hierarchy / relationships

StaticECS supports entity relationships, including:

• parent/child;
• owner/target;
• group membership;
• inventory-style links;
• one-to-one, one-to-many, many-to-many;
• deep copy/destroy operations over graphs.

Query system

Queries describe required data declaratively. Filters can combine:

• required components,
• excluded tags,
• entity type filters,
• change tracking,
• clusters,
• OR combinations.

Iteration modes include delegates, foreach, block access, and parallel iteration.

Change tracking

Change tracking uses the same bitmap infrastructure:

• added,
• removed,
• changed,
• created.

The article describes this as zero-allocation and native to the bitmap model, using tick-based ring buffers.

Event system

Events are separate from components because they represent moments, not persistent state. StaticECS uses a ring-buffer event system with independent cursors for receivers. An event is removed only after all relevant receivers have read it.

Resources

Resources are world-level data, such as configuration, camera reference, frame time, or network state. They are typed singleton-like values accessed through the static generic infrastructure.

Named resources are also supported.

Serialization

The article describes binary snapshots at multiple levels:

• whole world;
• cluster;
• chunk;
• selected entities;
• global ID store;
• events.

It also mentions compression, schema versioning, migration hooks, custom snapshot data, and pre/post callbacks.

---

13. Conclusion

The article’s central claim is that an inverted hierarchical bitmap is not a small optimization over archetypes or sparse sets, but a third ECS storage model.

The core principle:

Components index entities, rather than entities indexing components.

This changes the cost profile:

• component add/remove does not migrate entities;
• filtering happens through hierarchical bitmap operations;
• batch operations can work block-by-block;
• entity types and clusters add explicit control over memory layout.