ecs: a despawnWhere that matches nothing should cost nothing

Aperta
  • Qualcosa non va?
#252 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
performance

Direzione di ricerca

The payload names no source files. Start from how commands.despawnWhere is queued and how the sync point decides whether to run, using the #245 idle-sync-point work as the reference. The benchmarks derive cells idle 100k and drag frame select 256 reproduce the cost. Choose option 1 or 2 from the issue and confirm the empty-query frame costs what the idle frame does. Done when an empty despawnWhere no longer adds a sync point.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

commands.despawnWhere(query) issued by a system that runs every frame makes every frame pay for a sync point, even when the query matches nothing. A per-row system that calls commands.despawn(row.entity) makes no command when no row matches and so costs nothing. For a "clear last frame's events" system, which runs every frame and usually has nothing to clear, the batch call is slower than the loop it was meant to replace.

Where this came from (mecs)

mecs has an endFrame system that despawns every entity marked frameTransient (one-frame events). With 0.3.0 (#244) despawnWhere has the right meaning for it, so I tried:

export const endFrame = System.create({ after: [input] }, ({ commands }) => {
    commands.despawnWhere({ with: [frameTransient] });
});

Measured on the editor's frame (input, pointer, voxel and editor systems, nothing happening; the derive cells idle 100k and drag frame select 256 benchmarks, Apple M3, node):

endFrame idle frame drag-select frame
one despawnWhere each frame 5.5 µs 6.2 µs
per-row despawn (no rows, no command) 2.2 µs 3.1 µs

So an empty despawnWhere costs about 3 µs, roughly the frame. The idle-sync-point work in #245 skips a sync point that has nothing to apply, but a despawnWhere is a command, so the sync point can't be known empty until it is applied.

What I need

Any one of these would do; the first is what I'd reach for:

  1. A sync point whose only commands are despawnWhere (or other query-shaped commands) that match nothing costs what an idle one does: evaluate the query against the tables when the command is issued (or at the start of the sync point), and drop the command if no table matches, so the tier boundary can still be skipped.
  2. Or a cheap way for a system to ask "is there any row for this query" without a lookup/Index (the systems-use-queries rule in mecs says not to define an Index for what a query reads), so the caller can skip issuing it.

Why it matters

One-frame events and "clear then respawn if changed" are common (previewBrush in mecs clears and respawns its preview marks only when the brush changes, which is fine, but endFrame runs unconditionally). The pattern the guide's chapter 06 shows ("the producer clears its last events") is the same shape. Per-row despawn is the workaround, and it is fine, but it means the batch command is only a win when something matches.

Lingua principale
TypeScript
Stelle
12
Fork
8
Merge medio
11h 36m
PR unite (30g)
21

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di adobe/data

Tutte le issue di adobe/data

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.