ecs: a despawnWhere that matches nothing should cost nothing

未关闭
  • 哪里不对？
#252 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript
领域
performance

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
TypeScript
星标
12
派生
8
平均合并
11 小时 2 分钟
30 天内合并 PR
23

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

adobe/data 的其他 Issue

查看 adobe/data 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。