NoteGen 低配机器性能实测：4GB 内存够用，文件树扫描与长文档是两大卡点

NoteGen 低配机器性能实测：4GB 内存够用，文件树扫描与长文档是两大卡点

【免费下载链接】note-genCapture first. Organize later. A local-first Markdown app that turns scattered records into clear notes with AI.项目地址: https://gitcode.com/GitHub_Trending/no/note-gen

NoteGen 是一款本地优先的 AI Markdown 笔记应用：先把碎片化的文字、录音、截图记下来，再借助 AI 整理成结构化笔记。本文在 3 台低配机器上跑通了它的启动、编辑、AI 生成与导出全流程，回答两个问题：它到底慢在哪，以及往哪调最有效。

结论速览

• 最低可运行配置：4GB 内存 + eMMC 存储即可流畅日常记录；2GB 内存机器只建议开单文档、禁用知识库索引。
• 最大瓶颈：启动时对工作区做全量 Markdown 文件扫描，1200 个文件的 eMMC 笔记本上仅这一项就占掉 4.6 秒冷启动中的 1.5 秒（约 33%）。
• 提升空间最大的一项：把工作区文件数从 1200+ 收敛到 200 以内，启动扫描耗时从 1.5 秒降到 0.4 秒，是全文 ROI 最高的操作。
• AI 功能不吃 CPU：NoteGen 的模型走云端 API，低配机上的"AI 慢"主要是首包网络延迟（1.2~2.6 秒），不是本地算力问题。
• 实测版本：v0.37.1，Windows / Linux / Android 三端各取一台，每项数据重复 3 次取均值。

谁会在一台老机器上打开 NoteGen

不是所有人都用最新旗舰写笔记。更常见的画面是：

• 教师：用一台 2017 年的 4GB 内存老笔记本记录听课片段，课后用 AI 整理成教案；
• 学生：预算有限的入门平板（3GB 内存）上收集资料，周末整理成一篇长笔记；
• 小团队办公：公司配发的低配迷你主机（8GB）当文档库，笔记、会议纪要、周报都在里面；
• 老设备续命用户：主力机还在服役，只想找一个不卡、数据留在本地的 Markdown 工具。

这些场景的共性是：硬件给不了余量，任何"顺手的全量扫描"和"后台常驻任务"都会被放大成卡顿。下面的三个场景就按"启动 → 日常编辑 → AI 与重操作"逐段拆解。

三个场景的实测数据

场景A：冷启动与首屏（NoteGen 启动速度怎么优化先看这里）

测试设备：老旧笔记本 Intel Celeron N4020（4 核 / 1.1GHz）/ 4GB DDR4 / 128GB eMMC / Windows 11 22H2，工作区 1200 个.md文件。

以 N4020 的 4.6 秒冷启动为例，逐段拆分如下：

一句话诊断：启动慢的主因不是 Tauri 本身，而是"JS 包解析 + 工作区全量扫描"这两段都在和慢存储正面交锋。

场景B：日常编辑（输入、切换、多文档）

测试设备：同上 N4020 老笔记本为主，对照 N3550 迷你主机；文档规模为 2 万字纯文本。

内存占用（任务管理器实测，MB）：

一句话诊断：2 万字以内的日常编辑三台机器都不卡；越过 5 万字后，富文本编辑器的重排成本开始压垮弱 CPU，这是 3GB 平板最先撑不住的地方。

场景C：AI 生成、知识库与长文档导出

测试设备：N4020 老笔记本（4GB/eMMC），AI 走 OpenAI 兼容云端接口（国内线路），知识库 500 个文件。

一句话诊断：NoteGen 不加载本地大模型，AI 阶段的瓶颈是首包网络与流式渲染，CPU 余量充足；真正吃资源的是长文档渲染和 eMMC 上的知识库索引。

慢从哪里来：三层诊断

架构层：双进程桥接的固定成本。NoteGen 是 Rust（Tauri 后端）+ Web（Next.js 15 / React 19 前端）的混合架构。每次前端读文件都要经过 Tauri 桥接层一次 IPC 往返，单次约 2~4ms，开销不大；但启动扫描是 1200 次串行readDir，累积起来就是 1.5 秒。对比 Electron 系应用，这套架构内存反而更省（实测空闲 385MB），代价是文件类操作多了桥接层。

代码层：全量递归扫描。瓶颈点在 src/lib/files.ts 的工作区文件枚举逻辑：

// src/lib/files.ts：全量递归扫描，目录多时每次启动都跑一遍 async function processDirectory(dirPath: string, ...): Promise<void> { const entries = await readDir(dirPath) for (const entry of entries) { if (entry.isDirectory) { await processDirectory(join(dirPath, entry.name), ...) // 逐层递归 } else if (entry.name.endsWith('.md')) { files.push({ path: ..., relativePath: ... }) } } }

只要工作区目录多、文件多，启动就要完整走一遍树。长文档卡顿则与富文本编辑器（Tiptap + yjs）在 5 万字规模下的全量重排有关，代码位于 src/app/core/editor/ 目录。

使用习惯层：后台任务叠加。自动同步、知识库索引、图片托管压缩这三件事如果在弱机上同时跑，eMMC 的随机读写会被打满。实测同步 + 索引并行时，打字延迟从 240ms 恶化到 610ms。

一份能立刻执行的性能处方

⚡ 按成本分三档，从上往下做即可。

零成本（点几下）

1. 把工作区换成专门目录：旧笔记移出后文件数 1200 → 200，启动扫描 1.5s → 0.4s，1200 文件树首次展开从 2.8s 降到 0.7s。
2. 同时只开 1~2 个文档标签页；3GB 平板建议单文档。
3. AI 生成期间别点导出、别切预览，生成结束再继续。

配置级（设置页内调整）

1. 设置 → 同步：老机器关掉自动同步，或把同步间隔拉长到 5 分钟以上。
2. 设置 → 常规 → 系统行为：关闭启动时恢复最近文档；图片预览质量调低。
3. 知识库只索引需要的文件夹：500 文件全量索引 46s，改为 50 个文件约 5s。
4. 长文档写作时关闭实时预览，编辑完再切。

高级（启动参数）

# Linux（WebKitGTK 内核）：关闭 GPU 合成，仅核显/无独显机器 WEBKIT_DISABLE_COMPOSITING_MODE=1 note-gen # Windows：在快捷方式"目标"末尾追加，关闭 WebView2 硬件加速 note-gen.exe --disable-gpu

适用场景：集显老笔记本上出现画面撕裂、切换窗口花屏，或 GPU 占用异常时；核显流畅的机器保持默认即可。

设备分级与预警信号

🚨预警信号（出现任意一条立即处理）：

1. 打字延迟肉眼可感、P95 超过 500ms；
2. 标签页切换卡住超过 1 秒；
3. 系统总内存占用持续高于 85%。

出现后的动作顺序：

官方优化计划与参与入口

从源码与仓库动态看，团队后续会优先处理：文件树懒加载（只加载展开的目录，直接消掉场景A里最大的那 1.5 秒）、长文档虚拟滚动（缓解 5 万字以上的重排卡顿）、以及AI 流式渲染的分块优化。性能相关的进展与讨论可以在项目仓库的 issue / discussions 区域检索"performance"或"性能"关键词找到对应条目；复现时附上设备型号、内存、工作区文件数三个信息，比只说"很卡"有用得多。

一句话总结

NoteGen v0.37.1 在 4GB 内存老机器上的真实水位是：日常记录与编辑流畅，启动全量扫描与 5 万字以上长文档是两个明确卡点，把"工作区文件数"和"后台任务"管住，80% 的低配卡顿可以提前消掉。

数据免责：以上数字来自 v0.37.1 版本在受控环境（关闭后台应用、性能电源模式、每项重复 3 次取均值）下的实测，Windows / Linux / Android 三端各一台设备；你的系统负载、网络与存储状态不同，数值会有偏差。

【免费下载链接】note-genCapture first. Organize later. A local-first Markdown app that turns scattered records into clear notes with AI.项目地址: https://gitcode.com/GitHub_Trending/no/note-gen