Skip to content

performance-reporter.md

Latest commit

 

History

History
54 lines (39 loc) · 2.96 KB

performance-reporter.md

File metadata and controls

54 lines (39 loc) · 2.96 KB
Raw

内存占用 1G 调研报告

诊断 session a3593062 RSS 达 1.09 GB，定位 Bun 运行时内存膨胀根因

数据收集

  • 诊断数据: RSS 1,118 MB，V8 heap 84 MB，原生内存缺口 1,034 MB（92%）
  • 构建方式: bun run build:vite → Vite/Rollup 单文件构建，产物 17MB dist/cli.js
  • Vite 配置: codeSplitting: false（vite.config.ts:97），所有代码内联为单文件
  • Node.js 对比: 相同 17MB 产物，Node.js RSS 仅 223 MB（--version）/ 340 MB（完整加载）

探索与验证

已确认

问题 位置 说明
根因: Vite 单文件构建 + Bun 解析大文件内存效率低 vite.config.ts:97 codeSplitting: false 产出 17MB 单文件，Bun/JSC 解析时 RSS 暴涨至 966MB
Node.js 对同等 17MB 文件仅需 223MB 实测 V8 对大文件解析的内存效率远优于 JSC
Bun.build 代码分割可解决问题 实测 bun run build（代码分割 → 627 chunk）Bun RSS 仅 30MB（--version）/ 318MB（完整加载）

已否认

  • 不是 feature flags 数量问题 — 全部 35 features 开启时，代码分割构建内存正常
  • 不是内存泄漏 — detachedContexts: 0，activeHandles: 0
  • 不是原生 addon 问题 — vendor 文件仅 2.7MB
  • 不是 TypeScript 源码体量问题 — bun run dev（直接加载 TS）完整路径仅 345MB

结论

根因是 Vite 构建配置 codeSplitting: false，产出 17MB 单文件，Bun/JSC 解析单文件大 JS 时内存效率极差（966MB vs Node 的 223MB）。

实测对比矩阵：

构建方式 产物结构 Bun RSS Node RSS Bun/Node
build:vite 17MB 单文件 966 MB 223 MB 4.3x
build:vite pipe mode 同上 1,088 MB 340 MB 3.2x
build (Bun) 627 chunk 30 MB 42 MB 0.7x
build (Bun) pipe mode 同上 318 MB 253 MB 1.3x
bun run dev TS 源码 动态加载 42 MB — —
bun run dev pipe mode 动态加载 345 MB — —

核心差异：

  • Node/V8 解析 17MB 文件只需 223MB — V8 的懒解析（lazy parsing）只编译入口需要的部分
  • Bun/JSC 解析 17MB 文件需要 966MB — JSC 对单文件做全量编译，bytecode + JIT 占用大量原生内存
  • 代码分割后（627 个小 chunk），Bun 按需加载，内存回到正常水平

建议

  1. 开启 Vite 代码分割 — 在 vite.config.ts 中启用 codeSplitting: true 或使用 Rollup 的 manualChunks 配置。这是最直接的修复
  2. 或切换到 Bun.build — bun run build 已默认启用代码分割（splitting: true），Bun RSS 仅 30-318MB
  3. 如果必须单文件 — 考虑用 Node.js 运行 Vite 产物（node dist/cli-node.js），代价是失去 Bun 特有 API
  4. 验证 codeSplitting: false 的存在理由 — 注释说"all dynamic imports inlined"，可能是为了简化部署。评估是否真的需要单文件