Skip to content

feat(desktop): 重载、语义高亮与小地图的编辑器性能 (#1816) - #1946

Merged
xiaoyumuxi merged 4 commits into
previewfrom
fix/1816-editor-hot-paths
Nov 14, 2026
Merged

xiaoyumuxi merged 4 commits into
previewfrom
fix/1816-editor-hot-paths

Conversation

@xiaoyumuxi

Copy link
Copy Markdown
Collaborator

关联 Issue / Linked issue

PR 类型 / Type

  • feat:用户可见的改进(重载、语义高亮、超长行小地图的性能)

改动说明 / What changes

背景 / Why

#1816 列出的编辑器性能债务。本 PR 处理其中的重载、基线比较、语义高亮和小地图相关项。

改动 / Changes

  • 重载与冲突解决(第 3 项):PrepareAgainst 在工作线程算出变更范围,窗口线程只应用它,不再把整篇文本复制成字符串给 OnEdit。diskEdit 在基线不匹配时才回退到 rope.Diff。
  • 历史记录(第 3 项):historyTexts 可携带不可变 rope,字节副本在后台 job 中生成。
  • 基线比较(第 4 项):rope.EqualBytes 逐块比较,不再复制基线。
  • 语义高亮(第 5 项):PrepareSemantic 在工作线程转换 token,窗口线程只调用 SetPreparedSemantic;buildSemantic 按 Chunks 读一遍文本,行内用游标推进。
  • 基准:新增 BenchmarkEditorViewReload、BenchmarkEditorSyntaxSemanticBuild、BenchmarkEditorViewType/longline-wrap-minimap,并在 editor-budgets.json 补预算。

不在本 PR 范围内 / Out of scope

  • 第 1 项(StateStack 分配):做过 slab 分配,分配次数 27.7k → 7.1k,但耗时不变(约 54 ms),字节数 +15%,已撤回,不做。
  • 第 6 项(正则回溯):内置语法 6400 个正则中只有 36% 能被 Go regexp 编译,其余需要前后查找、占有量词、原子组或 \G。真正解决需要支持这些特性的非回溯引擎,单独立项。
  • 第 7 项((?:\n|$) 首字符剪枝):未做,需要改首字符分析,收益只限这一类模式。
  • 已知回归(未解决):BenchmarkEditorViewType/longline-wrap/10MiB 从约 78 µs 到约 94 µs(+20%),两轮测量一致。二分确认来自 view.go 的改动(单独还原 rope.go 无效),在输入路径上没有找到原因。仍低于 1 ms 预算。

类型专属:feat

多平台对齐

  • 两端都具备:编辑器代码 macOS 与 Windows 共用,但 Windows 未运行测试和基准,待验证后勾选。

范围检查 / Scope checks

性能与内存 / Performance and memory

同一台 Apple M4,空闲时运行,-test.count 3,基线为 origin/preview(295ee28d6),新版为本分支。

场景 改动前 改动后
Reload 10MiB(窗口线程,不含绘制) 约 400 µs,10.5 MB/op 约 70 ns,183 B/op
Reload 100KiB 约 4.4 µs,106 KB/op 约 37 ns,183 B/op
SemanticBuild go 10MiB 约 23 ms 约 5.2 ms
SemanticBuild go 100KiB 约 185 µs 约 39 µs
SemanticBuild longline 100KiB(400 token) 约 13.5 ms 约 79 µs
ViewType longline-wrap-minimap 10MiB 约 298 µs 约 316 µs(+6%,见回归说明)
ViewType longline-wrap 10MiB 约 78 µs 约 94 µs(+20%,见回归说明)
ViewType go / longline / minimap,ViewPaint wrap / minimap / longline 无变化(±1%) 无变化

无用代码与重构 / Dead code and refactoring

  • 删除了无调用方的 wholeDocumentEdit,widestLine 等仍在使用,保留。
  • 撤回的 slab 分配不在本 PR 中。

验证 / Verification

命令或操作 平台 结果
scripts/desktop/desktop-go.sh test ./internal/editor/... ./internal/editorview/ ./internal/workbench/ macOS arm64 全部通过(工作台约 157 s)
go vet(editorview、editor/...、workbench) macOS arm64 通过
gofmt -l macOS arm64 无输出
node --test scripts/desktop/perf/editor-perf-report.test.mjs macOS 23/23 通过

未能执行的检查和原因:

  • Windows 未运行测试和基准。
  • 未对回归做完整定位,见上。
  • 基准为无头 Go 基准,不代表真实窗口延迟。
  • scripts/desktop/verify/verify-runtime-bundle-immutability.sh 未运行;本 PR 不新增运行时资源或写入路径。

提交前确认 / Final checks

  • 分支从最新 preview 创建(295ee28d6),目标分支 preview
  • 以 Draft 提交,本地验证通过后才标记 ready
  • 没有无关改动,没有提交产物

- Content 带着基线计算出的变更范围(PrepareAgainst),窗口线程只应用它,不再复制整篇文本作为 OnEdit 的编辑
- 基线与磁盘内容是否相同改为逐块比较(rope.EqualBytes),不再复制基线
- 历史记录的文本副本改在后台 job 里生成,窗口线程不复制
- 新增 BenchmarkEditorViewReload 与预算:10 MiB 重载从约 420 µs、10.5 MB 分配降到约 70 ns、0 B
- PrepareSemantic 在工作线程转换 token,窗口线程只调用 SetPreparedSemantic 应用结果(原先 provider 路径在窗口线程上转换)
- buildSemantic 按 Chunks 顺序读一遍文本,行号用换行符定位,只复制含 token 的行;同一行的 token 向前游标推进,不再从行首重新扫描
- 超长行 400 个 token:15.5 ms -> 84 µs;100 KiB Go 文档:191 µs -> 40 µs
- 新增 BenchmarkEditorSyntaxSemanticBuild、跨 leaf 的参考对比测试,以及线性预算
- BenchmarkEditorViewType 新增 longline-wrap-minimap 变体,覆盖小地图每次编辑重建的路径
@xiaoyumuxi xiaoyumuxi changed the title perf(desktop): 重载、语义高亮与小地图的编辑器性能 (#1816) feat(desktop): 重载、语义高亮与小地图的编辑器性能 (#1816) Nov 14, 2026
@ghfind-review ghfind-review Bot added the review: high ghfind author score; see https://ghfind.com label Nov 14, 2026
@xiaoyumuxi
xiaoyumuxi marked this pull request as ready for review November 14, 2026 18:30
@lithe-code-review

lithe-code-review Bot commented Nov 14, 2026 •

Copy link
Copy Markdown

Lithe Review

结论: ❓ 审查未完成

已由服务器取消。可以重新评论 @lithe review 召唤。

…t-paths

# Conflicts:
#	desktop/internal/workbench/semantic_tokens.go
@xiaoyumuxi
xiaoyumuxi merged commit 971ab2f into preview Nov 14, 2026
2 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

review: high ghfind author score; see https://ghfind.com

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant