|
|
cf3d3769b1
|
perf(starmap): WebUI/GUI 星图卡顿修复 + 抽出共享「布局数学」单一源
## 症状与实测
WebUI 星图建图阻塞主线程 9339ms、draw calls 7514；GUI 建图 2466ms、
draw calls 3477。两者在空闲时仍在空转渲染。
## WebUI（internal/plugins/webui/dashboard.js）
- 力导向布局 O(n²) 两两互斥改**网格近邻**，并移入 **Web Worker**
⇒ 建图阻塞 **9339ms → 57ms**
- 每节点光晕 3753 个 draw call → 1 个 InstancedMesh
- 边 966 → 4 个 LineSegments
- 空闲帧跳过 + 星空时间驱动
- 结果：draw calls **7514 → 3760**，空闲阻塞 **99% → 3%**
## GUI（cmd/gui/renderer/app.js）
- draw calls **3477 → 1809**，建图 **2466ms → 943ms**
- 首屏可见性守卫（GUI 默认 chat 视图，星图不该在后台初始化）
- 空闲 12fps → 0.2fps
修 GUI 两个自引 bug：
1. 抄 WebUI 的 `starmapMorphSet`（GUI 实际用 `state.starmapGrown`）⇒
每帧 ReferenceError、星图 0 帧；
2. `camKey` 读 `starmapCam.position` 无守卫（`switchChatPanel` 同步调
`starmapAnimate` 时 cam 为 nil）。**同一缺陷 WebUI 也存在，两处均已补守卫。**
## 共享源（方案 A：只共享「布局数学」这一层）
新增 `shared/starmap/layout.js`（3 个纯函数，零 DOM/全局引用）+
生成器 `tools/starmap-sync.mjs` + 门禁 `make check-starmap-shared`（已进
make test）。三处（共享源 / dashboard.js / app.js）的标记块必须逐字节相同。
**为何只共享这一层**（实测依据）：web 星图 54 个函数、gui 24 个，两者同名
函数逐字节相同数为 **0**。GUI 有设备桥/computer use/托盘/自有面板，WebUI 有
侧栏页签体系 —— 共享受众完全不同的 UI 代码是错的，能安全共享的只有布局数学。
**为何用生成器而非运行时加载**：GUI 用 file:// （main.js 的 loadFile），可能
离线；让其拉服务端 dashboard.js 会把「星图能否初始化」绑到网络与登录态上。
**为何 GUI 不用 Web Worker**：file:// 下外链与 Blob Worker 实测都能跑，但不把
「星图能否初始化」押在打包环境的 Worker 行为上。
## 判据
- `cmd/gui/starmap-perf.test.mjs`（21 条，接入 npm test）
- 扩充 `internal/plugins/webui/starmap_perf_test.go`（同源判据 +
checkStarmapSharedBlock）
- 变异 M1/M2/M3 全部报红
## 附带
cmd/gui/renderer/app.js 同时含上一提交的 GUI `system` 事件消费（协议修复），
因同文件交织未再拆分，见提交 fix(clients)。
|
2026-10-13 16:21:04 +08:00 |
|
|
|
c7da8fde82
|
perf(webui): 星图力导向布局改网格近邻 + Web Worker，消除主线程 10.9s 阻塞
生产库 3754 块时，buildChatStarmapGraph 在内联脚本里同步跑 50 轮全对全
（O(n²)）斥力：每轮 704 万次配对，50 轮共 3.52 亿次。CDP Profiler 实测
单次阻塞主线程 10.9 秒，页面启动首帧 11.8 秒；PerformanceObserver 在
40 秒窗口统计到累计 40,005ms 长任务。
两条独立问题叠加，本提交分别解决：
① O(n²) → 网格近邻（O(n·k)）
斥力体里本来就有 `if (d < 25)` —— 只对近邻施力，全对全是白算。
改为 3×3×3 网格分桶，只遍历邻近格。实测 3754 节点 7016ms → ~120ms。
② 同线程 → Web Worker
即使算量合理也不该占主线程。计算整体移入
static/starmap-layout-worker.js，主线程零阻塞。
配套：迭代数按 n 自适应（小图跑满 50 轮，大图退到 14 轮）+ 迭代间早停
（阈值取平均间距的 0.2%，随规模自适应）。
★ 串行回退（file://、老浏览器、Worker 构造失败）必须用**同一算法**。
若回退走旧全对全，两条路径会给出不同布局 —— 「有 Worker 和没 Worker
看到的图不一样」极难排查。故两边各写一份逐字对应的实现。
★ 另修：renderChatStarmap 必须在容器不可见时提前返回（offsetParent）。
starmapActiveContainer 会 fallback 到聊天面板，导致未打开星图也被迫
建图，把聊天页签一起拖死。
判据 TestStarmapNoPerFrameFullScan 同时覆盖两处实现，经三向变异验证：
① 回退改回 Object.keys 全对全 → FAIL
② Worker 去掉 CUTOFF 网格法 → FAIL
③ 删除 Worker 文件 → FAIL
|
2026-10-13 10:12:57 +08:00 |
|
|
|
8336509bfa
|
perf(webui): 修星图形变活跃集的泄漏 + 加回归判据
上一提交（3e201dd4）把 starmapTickMorph 从「每帧全量遍历」改成
starmapMorphSet 活跃集，但我漏了一处：buildChatStarmapGraph 重建图时
只重置了 starmapNodeMeshes / starmapEdgeLines，**没清空 starmapMorphSet**。
后果：旧 mesh 已从场景摘掉，却留在活跃集里，于是
- 集合随每次重建单调增长、永不归零 ⇒「空集时 O(1) 返回」的快速路径
从此失效，正是这次优化想省掉的那笔开销又回来了
- 每帧遍历一批已经不在场景里的废弃 mesh
同时补 starmap_perf_test.go。为何用源码断言而非运行时测量：
dashboard.js 是嵌入的浏览器脚本（依赖 three.js / DOM），Node 跑不了；
而这几条都是**结构性**缺陷（循环扫全表、循环不停、每帧重建），
源码里能可靠判定，回归时立刻红。
判据可杀变异（逐个实测过，不是装饰）：
- 节流常量改名 → FAIL「缺少节流」
- morph 早退条件删掉 → FAIL「必须提前返回」
- clear() 改成 if (false) 或整行删除 → FAIL「必须无条件清空」
第三处特意断言在**重建函数体内**且是 `(?m)^\s*if \(starmapMorphSet\) ...`
（先写成全仓搜 `starmapMorphSet.clear()`，变异测试显示 `if (false)` 能骗过
它 —— 弱判据当场修强）。
|
2026-10-08 12:40:43 +08:00 |
|
