[P0][ECS] Reproducible ECS benchmarks and memory baselines

Open
  • Is something wrong?
#132 5 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@bozoslav is already working on this.

Since Nov 11, 2026.

Assessment

This issue has not been assessed yet.

Description

area: ecs help wanted priority: P0 type: performance

Problem and goal

Establish a representative, reproducible performance baseline before redesigning storage or scheduling.

Implementation scope

  • Benchmark 1k/100k/1M homogeneous iteration; many small archetypes; optional and filtered queries; query construction; spawn/despawn; add/remove component churn; batch spawning; and parallel scaling.
  • Include one mixed game-like workload with multiple component layouts and systems.
  • Compare with a pinned bevy_ecs version using equivalent operations and clearly documented limitations.
  • Record memory, allocations, p50/p95, compiler/toolchain, hardware, feature flags and warm-up.

Acceptance criteria

  • One documented command exports machine-readable results.
  • Correctness is verified separately from throughput.
  • Baselines and benchmark methodology are committed; no flaky wall-clock CI thresholds.

Relevant code

  • crates/crabby_ecs/
  • src/game.rs

Dependencies and notes

Precedes all performance-motivated ECS changes.

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: Extend the existing ponko_bench runner (crates/crabby_bench/src/main.rs); the physical directory is retained after the rename. Existing iteration comparisons, warmup and summaries are starting points, not the full acceptance matrix.

First slice: Add many-small-archetype and repeated-query-construction cases with machine-readable output, then extend memory/churn/scaling coverage.

Dependencies and coordination: Baseline for performance-driven ECS work; coordinate with #133.

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.