sublime text启动快、加载快、滚动快、搜索快、保存快，因其原生c++设计、mmap文件映射和惰性加载机制；vs code因electron框架需启动chromium、lsp、git等服务，冷启动2.12秒，大文件滚动易掉帧。
Sublime Text 不是“比 VS Code 快一点”，而是从启动、加载、滚动、搜索到保存，每个环节都绕开了 Electron 和语言服务的通用开销——它快在不做那些 VS Code 认为“理所当然”的事。
冷启动为什么只要 0.4 秒？
VS Code 启动时要拉起 Chromium 渲染进程、初始化扩展主机、加载语言服务器（LSP）、扫描 Git 状态、读取 settings.json 和 keybindings.json，哪怕你只打开一个空文件。Sublime Text 启动只做三件事：malloc 主窗口、映射 UI 字体、初始化命令面板缓存。
实测同一台 M2 MacBook Air（16GB）上：
-
time open -a "Sublime Text"平均耗时 0.38 秒 -
time open -a "Visual Studio Code"首次启动平均 2.12 秒
关键区别：open -a 测的是真实冷启；若 VS Code 已在后台运行，open -a 只是唤起窗口，不反映真实延迟。
打开 500MB 日志为何不卡？
Sublime Text 不把整个文件读进内存，而是用 mmap 将文件直接映射到虚拟地址空间，滚动时仅按需解码可视区域前后几屏的 UTF-8 行——长日志里跳到末尾，它甚至不解析中间那 499MB 的内容。
VS Code 默认启用 largeFileOptimizations，但依然会尝试构建 AST、触发语法高亮、监听文件变更，导致：
- 首次滚动有明显掉帧（尤其 macOS 上未启用 Metal 渲染时）
-
top中 RSS 常飙至 400MB+，Sublime 同样操作通常 - 远程 SFTP 打开大文件时，VS Code 卡在“等待完整响应”，Sublime 可边下边看
顺手一提：view.settings().set("word_wrap", false) 强制关换行，能避免长日志行二次渲染开销。
Ctrl+P 搜索为什么比 Cmd+P 快 30%？
Sublime 的 Ctrl+P 是纯内存哈希索引，只扫文件名和路径，不分析内容语义，也不依赖后台进程。项目含 5000 个文件时，响应常在 50ms 内。
VS Code 的 Cmd+P 默认走 files.associations + search.exclude + ripgrep 后台扫描，首次搜索常触发全量文件遍历，大项目里可能卡顿 2–3 秒。
容易被忽略的配置点：
- Sublime 要让索引包含子目录，得手动加
"folder_exclude_patterns": [".git", "__pycache__"]到Preferences.sublime-settings - VS Code 若
files.watcherExclude配错，inotify 句柄耗尽会导致 CPU 持续 30%+ 占用
插件真的不影响速度吗？
Sublime 插件（如 GitGutter、SideBarEnhancements）是 Python 写的，加载慢一点但不驻留主进程——它们只在被调用时短暂激活，执行完即释放。而 VS Code 插件常以 Node.js 进程长期驻留，尤其带 LSP 或状态监听的插件（如 ESLint、Prettier），一开就占内存、抢 CPU。
但注意：装一堆 LSP 插件（如 LSP-pyright + LSP-eslint + sublime_debugger）后，Sublime 也会变慢。这时候不是编辑器变重了，是你把它当 IDE 用了——而它本意只是“打开就用、改完就关”。
真正容易被忽略的，是 GPU 渲染开关：macOS 上 hardware_acceleration 默认开启，但旧 Intel 核显（如 HD Graphics 4000）可能 fallback 到软件渲染，百万行日志拖动就会掉帧。
