sublime text启动后rss稳定在80–120mb，因其核心引擎按需加载：c++实现的轻量内核仅初始化基础模块，语法高亮、插件、语言服务均惰性触发，且界面直调系统原生api，无electron类冗余开销；大文件通过mmap异步分块加载，仅驻留可视区域内容。
为什么 Sublime Text 启动后 RSS 常稳定在 80–120MB
它压根没加载你没用到的功能。C++ 写的核心引擎只初始化文件映射、渲染管线和事件循环，sublime_text 进程启动时连语法高亮都未激活——等你打开 .py 文件才载入 Python 语法定义，打开 .js 才加载 JS 模块。
- 所有插件默认惰性加载：
Package Control安装完不自动启用，LSP插件要等你打开对应语言文件才 fork 子进程 - 界面控件直接调用 OS 原生 API（Windows 的 GDI / macOS 的 Metal / Linux 的 OpenGL），跳过 Electron 那套 Chromium 渲染层的数百 MB 基线开销
- 任务管理器里看到的内存值是真实 RSS，不是 V8 堆 + 渲染进程 + Node.js 沙箱的叠加值
mmap + 异步分块加载如何撑住 2GB 日志文件
它根本没把整个文件读进内存。用 mmap() 把文件虚拟地址空间映射进来，滚动时只把可视区域前后几屏的内容页加载到物理内存，其余部分停留在磁盘映射状态。
- 首次打开大日志，
top显示 RSS 通常 - 不解析 AST、不建符号表、不跑语言服务器——滚动就是纯内存拷贝+GPU 光栅化，CPU 几乎不参与
- 远程 SFTP 查看时，边下载边渲染已接收块，不像 Electron 编辑器卡在“等待完整响应”
共享内存池怎么实现跨项目去重
相同路径的文件内容对象全局复用。比如你同时打开 /src/main.py 和 /test/main.py（内容一致），Sublime Text 不会存两份副本，而是用前缀压缩字符串 + 弱引用哈希表统一管理。
-
LRU算法控制空闲缓冲区释放时机，避免频繁 GC 打断编辑流 - 同一会话中多个项目共用一个文本缓冲池，
.gitignore里排除的目录（如node_modules）不会被缓存，也不计入去重统计 - 这个机制对多仓库开发特别友好，但前提是别手动改
view.settings().set('enable_memory_pool', False)
Ctrl+P 搜索快的本质不是算法，是它不做啥
它的索引只是纯内存哈希表，只存 file_name 和 file_path，不扫描内容、不建倒排索引、不监听 inotify 句柄。5000 个文件的项目，Ctrl+P 响应在 50ms 内，因为根本没后台服务在跑。
- 默认关闭
file_watcher_enabled，省掉成百上千 inotify watch descriptor - 排除目录靠
folder_exclude_patterns静态配置，不是靠实时 fs event 过滤 - 一旦你装了
SublimeCodeIntel并开启"live": true，它就开始建 AST、驻留符号表——这时候就不是“轻量”了，是“自己加的重量”
真正容易被忽略的是：Sublime 的轻量，不是删功能删出来的，而是从设计第一天就决定“不干 IDE 认为理所当然的事”。你装十个 LSP 插件还抱怨卡，不如先问自己——此刻到底需要跳转定义，还是 just want to grep a log?
