Orkuncakilkaya
347352cc4c
Ludic's ECS is already pool-based — the allocator recycles freed entity slots through a freelist (L_alloc pops @L_freen before growing @L_entc), and component storage is fixed per-entity arrays, so spawn/despawn churn (bullet-hell/horde) does no per-spawn heap allocation and cannot fragment. Expose that with a Pool.* namespace so a game can watch reuse: Pool.live (alive now), Pool.free (recycled slots waiting), Pool.reserved (high-water — stays flat across a steady spawn/despawn loop, proving reuse not reallocation), Pool.capacity (the fixed cap). Zero-cost inline reads of the existing counters. Example pool.ludic proves the key property: after despawn+respawn, Pool.reserved() stays 3 (freed slot reused) — prints 0 0 3 3 0 2 1 3 0 3 1. 4 docs pages. Full suite 118/0, goldens byte-identical, fixpoint holds. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
14 lines
550 B
Markdown
14 lines
550 B
Markdown
---
|
|
id: pool-reserved
|
|
name: Pool.reserved
|
|
category: pool
|
|
kind: namespace-method
|
|
tokens: Pool.reserved
|
|
sig: Pool.reserved() -> int
|
|
tip: High-water: how many slots have ever been allocated.
|
|
order: 3
|
|
ns: Pool
|
|
member: reserved
|
|
---
|
|
|
|
Returns the high-water mark — how many entity slots have ever been allocated. It only grows when a <code>spawn</code> finds the freelist empty; a spawn that reuses a freed slot leaves it unchanged, so a steady-state spawn/despawn loop keeps <code>reserved</code> flat (the proof that slots are pooled, not reallocated).
|