第 18 章：性能、可靠性与测试——交互式系统如何证明自己

Zed 的性能不是最后加上的优化开关，而是数据结构、快照边界、异步所有权、渲染批处理和测试替身共同 塑造的结果。本章把这些机制放进同一套成本模型。

1. 先看源码规模，而不是用规模代替结论

本次快照的机械统计：

• 241 个 crates/ 一级 crate；
• 1,852 个 Rust 源文件；
• 约 152 万行 Rust（包含测试、fixture 与生成/平台代码）；
• 约 7,943 个 #[test]、#[gpui::test]、#[test_case] 等测试标记。

这些数字说明验证必须分层、不能依靠一个全量集成测试；它们不直接等于代码质量，也不能与别的项目在 不同统计口径下简单比较。

2. 16ms 帧预算只是最外层

60Hz 下从 input 到 present 约有 16.7ms，但编辑器还同时承担：

• 文本 mutation 与 Anchor 更新；
• syntax/inlay/fold/wrap 等 DisplayMap 计算；
• element layout、prepaint、paint；
• glyph shaping 与 GPU submission；
• LSP、Git、search、Agent 的后台事件；
• autosave、telemetry 与协作发送。

性能设计的目标不是让每项都“尽可能快”，而是让昂贵工作可增量、可取消、可移出前台，并限制一次更新 触发的无关工作量。

3. SumTree：用 summary 换增量查询

Buffer、Rope、DisplayMap 多层都需要回答 offset ↔ point、行高累计、fragment boundary 等前缀查询。 sum_tree 节点保存可组合 Summary；seek 时根据累计 Dimension 跳过整棵子树，更新时只重算修改路径。

全量数组：修改 O(n)，前缀查询 O(1) 或反之
平衡树 + summary：修改 O(log n)，seek O(log n)，顺序扫描摊销低

真正价值不只是 Big-O：同一棵树可定义多个 Dimension，让调用方按字节、UTF-16、Point、DisplayPoint 等 不同坐标 seek，而底层结构保持一致。

4. Copy-on-write Snapshot 把读写解耦

后台 syntax、LSP change conversion、search、paint 都需要稳定文本视图。若长任务持有 Buffer mutex，会阻塞 输入；若直接读可变结构，会得到混合版本。

Zed 让 Buffer/Rope/Map 产生廉价 Snapshot，结构节点共享，编辑只复制受影响路径。异步 task 捕获 snapshot 和 version，完成时验证结果是否仍适用。

UI: edit v41 → 发布 snapshot v41 → 继续 edit v42
BG: 读取稳定 v41，计算结果
UI: 收到结果 → 能映射到 v42 则应用，否则丢弃/重算

5. Patch 让失效范围可传播

一次 Buffer edit 不应使整个文件重新 wrap、shape 和 paint。各投影层将底层 patch 映射到自身坐标，再扩张 到必要的稳定边界，例如受影响的行、fold 或 wrap paragraph。

性能取决于 invalidation 精度：范围太小会显示旧状态，范围太大则退化为全量重算。为 patch mapping 写属性 测试比为最终截图堆特例更有效。

6. Viewport virtualization

Editor 对超大文件不能为每一行创建完整 element。布局从可见 scroll range 反推 display rows，只 materialize viewport 和少量 overscan；不可见 block/fold 仍以 summary 高度参与 scroll bounds。

滚动时复用仍可见的 shaped line/cache，只为新进入 viewport 的行工作。行号、selection、diagnostic decoration 也应在同一 visible range 裁剪，避免每帧遍历全文件。

7. 三阶段渲染避免边遍历边污染全局状态

GPUI element 的 request_layout、prepaint、paint 分离：

• layout 计算尺寸和位置；
• prepaint 解析 hitbox、clip、scroll、复杂几何；
• paint 只向 Scene 提交 primitives。

Scene 再按 pipeline/texture/clip 等条件排序和 batch，减少 GPU state change。稳定 subtree 可以 cache/replay， 不必因上层一次无关 state change 重新构造全部 primitive。

8. 异步并不自动等于流畅

后台 task 如果每完成一个小结果都 cx.update，仍会淹没前台。Zed 重复使用三种策略：

1. stream producer 批量发送；
2. consumer drain 当前 ready 的结果，一次更新；
3. generation/version 过滤晚到结果。

Agent token batching、project search stream、worktree scan、LSP diagnostics 都适用。关键指标是主线程更新次数 和每次 invalidation 范围，不只是 worker CPU 时间。

9. Task 所有权就是取消策略

搜索 query、hover、completion、render preparation 等任务通常由拥有它的 Entity 保存。新请求替换旧 Task； Entity/drop 或 window 关闭时 handle 被释放并传播取消。

若把 task 无条件 detach，其结果可能在所属 UI 消失后回写，或者继续占用 CPU/network。只有确实需要越过 发起者生命周期的工作（例如必要的 flush）才应 detach，并自行持有明确的完成/错误通道。

10. 启动路径的并行与延迟加载

启动不应串行等待所有 feature：配置/主题和窗口必需状态优先；extension index 使用缓存；telemetry、更新检查、 extension rebuild 等后台执行；大型 registry 按需要初始化。

并行启动仍需明确依赖图。把所有步骤塞进 join_all 会隐藏顺序约束并放大 I/O 争抢，最好让每个 task 的 输入是不可变 snapshot，最终在 UI context 中做短小提交。

11. 测试金字塔映射到架构层

层	主要验证	常见工具
纯数据结构	SumTree/Rope/Anchor/patch 不变量	unit + property/randomized tests
Entity/异步模型	event、task、transaction、取消	#[gpui::test]、TestAppContext
领域服务	Project/LSP/Git/search local/remote 一致	FakeFs、FakeLanguageServer、mock client
UI	action、focus、selection、layout	TestWindowContext、semantic assertions
协议/分布式	重排、断线、重连、收敛	simulated peers/network、mock remote
端到端	关键用户旅程与平台集成	integration/e2e、少量真实进程

越靠底层越适合穷举和随机化；越靠上层越应该只覆盖关键组合，否则测试既慢又难定位。

12. #[gpui::test] 提供确定性运行环境

普通 Rust test 没有 App/Window/ForegroundExecutor。GPUI test harness 创建 TestAppContext，允许测试：

• 创建和更新 Entity；
• 模拟 background/foreground task；
• 推进事件与等待 condition；
• 建立 window/focus/action；
• 读取状态而不启动完整 OS 应用。

测试应优先等待可观察状态，而不是 sleep(100ms)。固定 sleep 在慢 CI 上不够，在快机器上又浪费时间。

13. FakeFs 是 Project 测试的基石

Worktree、Git discovery、Buffer open/save、search 都依赖文件系统。FakeFs 在内存中建立目录/文件、控制事件， 使测试能精确构造：

• ignore/symlink/case sensitivity；
• 文件在 scan 中途新增或删除；
• save error、permission 与 external change；
• local/remote path 映射；
• 不依赖开发机上的真实 repo。

替身应模拟语义与时序，而不只是返回固定字符串，否则无法发现 scan/watch 竞态。

14. FakeLanguageServer 与协议断言

LSP 测试需要控制 initialize capability、request response、publishDiagnostics 和 server crash。Fake server 记录 收到的 didOpen/didChange/version，让测试断言增量同步，而不是只断言 UI 最后出现一个 completion。

同一组 Project/LspStore 行为可对 local fake process 与 remote proto adapter 运行，能有效防止 local/remote 分支漂移。

15. CRDT 要用生成式与多副本测试

协同 Buffer 的关键性质是不同合法交付顺序最终收敛。典型测试：

1. 生成多个 replica 的随机 insert/delete；
2. 随机延迟、分批并重排 operation；
3. 确保依赖满足后应用；
4. 比较所有 replica text、version 与 Anchor 解析；
5. 缩减失败序列成为最小反例。

只写“A 输入 hello，B 收到 hello”无法覆盖并发删除、undo、离线积累和 Anchor bias。

16. Agent 测试应替换模型，而非匹配自然语言

Fake model provider 产生确定的 event stream：文本 chunk、不完整 tool JSON、多个并行 tool use、rate limit、 中途 stop。测试断言 Thread state、权限请求、工具次序、取消和 transaction，而不是依赖真实模型每次生成同一句话。

需要单独覆盖 model stream permit 释放、tool producer 异常关闭、compaction 边界与拒绝修改后的 checkpoint 恢复。

17. 可观测性与 hang detection

性能回归和死锁常无法从 crash stack 看出。应用需要 tracing span、长任务/主线程 stall 记录、hang detector、 crash handler 与关键队列长度。span 应携带 project/window/entity 或 operation id，但避免记录用户源代码等敏感内容。

一次卡顿的诊断链应能回答：输入事件何时到达、哪次 Entity update 最慢、是否触发全量 DisplayMap、GPU 是否 等待、哪个后台 task 持有稀缺 permit。

18. 容易制造回归的模式

• 在 paint 中做文件 I/O 或锁等待；
• 每个 token/搜索结果触发一次全窗口刷新；
• 跨 await 保存裸 offset 或可变借用的假设；
• query 变化后仍接受旧 task 结果；
• 为“简单”把 snapshot 换成全局 mutex；
• remote 模式偷偷 fallback 到本机路径；
• 测试只看最终文本，不验证 operation/version；
• benchmark 小函数，却不测 invalidation 扇出和 frame time。

19. 建议的性能验收矩阵

场景	主要观测
超大单文件输入	keystroke latency、增量 map 范围、allocations
大仓库首次打开	time-to-window、scanner CPU/I/O、index cache
快速滚动	frame time、shaped line cache、GPU batches
快速连续搜索	cancellation latency、旧结果丢弃、UI update rate
多人同时编辑	convergence、operation queue、Anchor 稳定性
Agent 多工具	event batching、permit、permission/undo
Remote 高延迟断线	local input latency、reconnect、resync correctness

平均值不够；交互性能应关注 p95/p99、最长主线程 stall 和退化时是否保持正确状态。

20. 可迁移经验

1. 性能预算落实为数据结构与 invalidation 边界；
2. snapshot 让后台读不阻塞前台写；
3. patch/generation 同时解决增量计算与过期结果；
4. viewport 与 Scene batch 控制每帧工作上限；
5. Task handle 的所有权决定取消与回写合法性；
6. 测试替身模拟时序与失败，不只是 happy-path 返回值；
7. 对 CRDT、坐标映射使用属性/随机测试；
8. 用 tracing/hang evidence 解释尾延迟，而非凭感觉优化。