[P3][ECS] Evaluate sparse-set storage for extremely sparse/tag-heavy data

Open
  • Is something wrong?
#166 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
48/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
game-dev

Research direction

Start with crates/crabby_ecs/src/storage.rs and crates/crabby_ecs/src/query.rs, then review #132 for the workload to extend. Benchmark sparse/tag-heavy churn against current archetype storage across memory, iteration, mutations, and filtering, and document the public query API implications and a keep/reject recommendation with maintenance costs. Keep archetype storage as the default; no storage rewrite is part of this investigation.

Written by the indexing model from the issue text.

Description

area: ecs help wanted priority: P3 type: research

Problem and goal

Archetype-based storage is a strong default; hybrid storage should only be added if a real workload requires it.

Implementation scope

  • Construct a realistic workload where sparse, optional or frequently modified components cause archetype proliferation.
  • Benchmark a small isolated sparse-set prototype vs current columnar archetypes.
  • Measure memory, iteration, mutations, filtering and integration complexity.
  • Write a keep/reject recommendation with maintenance cost.

Acceptance criteria

  • Decision supported by equivalent benchmarks.
  • No default storage rewrite as part of the investigation.
  • Public query API implications documented.

Relevant code

  • crates/crabby_ecs/src/storage.rs
  • crates/crabby_ecs/src/query.rs

Dependencies and notes

Research only; not part of the near-term roadmap.

Compatibility: preserve existing public Rust and C/C++ APIs unless an independently approved design explicitly requires a breaking change. Collect correctness results and before/after measurements for performance-oriented changes.

Source audit and first contribution (2026-11-09)

Reviewed against source baseline df5c1d4 and merged implementation PRs through #167. The full issue acceptance criteria are still open; this audit does not mark the task complete. Existing priority is unchanged.

Starting point: Archetype storage remains the default; no evidence in this audit justifies replacing it.

First slice: Extend #132 with a realistic sparse/tag-heavy churn workload before a small hybrid-storage prototype.

Dependencies and coordination: Retain P3. Measure full mutation/query/memory costs and distinguish #144 membership indexing.

Focused Rust-only PRs are welcome; a contributor need not complete this entire issue in one PR or also implement C/C++ bindings and guide chapters. Maintainers coordinate scoped documentation/native follow-ups. Preserve existing compatibility and supply tests/evidence relevant to the slice.

Dominant language
Rust
Stars
4
Forks
0
Avg merge
45m
Merged PRs (30d)
199

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ponkoengine/ponko

All issues in ponkoengine/ponko

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.