atom性能测试需通过源码根目录运行npm run benchmark，指定benchmarks/下具体测试文件，关注constructeditor和settext阶段毫秒数，禁用插件须用apm disable命令，config.cson修改后必须重启才生效。
Atom 本身不执行代码，所以不存在“测试代码运行速度”这件事——你真正要测的是编辑器自身响应、渲染、解析的耗时。 所有卡顿、延迟、内存爬升，都来自 Atom 自身或插件的行为，而不是你写的 JS/Python 脚本。别在 console 里跑 console.time()，那测的是 Node/V8，不是 Atom。
怎么用内置 benchmark 工具测编辑器真实性能
Atom 的 benchmarks/ 目录是唯一能复现真实编辑场景并量化耗时的路径，不是玩具。
- 必须从源码根目录运行：
npm run benchmark，直接双击启动或atom --benchmark无效 - 关键测试文件要手动指定才有意义：
atom --benchmark benchmarks/text-editor-large-file-construction.bench.js - 报告输出在控制台，不是弹窗——看
ms数值，重点关注constructEditor和setText两个阶段 - 图形报告依赖本地
Chart.js，若报错Cannot find module 'chart.js'，先npm install chart.js
为什么 Performance 面板录不到关键卡点
Chrome DevTools 的 Performance 标签页只能捕获渲染线程行为，但 Atom 卡顿大多发生在主线程的同步 JS 执行（比如 Tree-sitter 解析、minimap 生成 Canvas），这些操作默认不被录制。
- 必须勾选
JS stack traces和Memory，否则看不到treeSitter.parse或minimap.redraw的调用栈 - 录制前先触发一次
Ctrl+Shift+I→Console→ 输入performance.mark('start')，再操作，否则时间轴对不上 - 滚动卡顿几乎总是
updateSyncedScrollState函数占满帧，它在每帧都同步计算所有行的折叠/高亮状态
config.cson 里哪些设置真影响 benchmark 结果
改完 config.cson 不重启 Atom，benchmark 数据完全不可信——很多配置只在初始化时读取一次。
-
core.largeFileMode: true：仅对 > 2MB 文件生效，且必须配合useTreeSitterParsers: false，否则 Tree-sitter 仍会尝试解析 -
editor.softWrap: false：软换行开启后，text-editor-large-file-construction.bench.js的setText时间会翻倍 -
core.excludeVcsIgnoredPaths: true：影响project.scan阶段耗时，但 benchmark 默认不测项目扫描 - 禁用插件必须用
apm disable linter-eslint，而不是在 UI 里开关——后者只是暂停，进程仍在后台
benchmark 数据里最常被忽略的细节是：它测的是“冷启动构造”，不是你日常开着 10 个 tab 的持续负载。真实卡顿往往来自内存泄漏积累，得靠 Memory 面板连续拍 3 次快照比对 Retained Size 增长量，而不是看单次 benchmark 的 ms 数字。
