性能基准
本文说明 utoo 包管理器基准测试中的不同指标、测试口径和如何解读结果。完整数据来源见 GitHub issue #3250 。
表中的耗时越低越好。不同平台、镜像源、网络拓扑和文件系统会影响绝对耗时，因此不同环境的结果不应直接混合做统计比较。
指标说明
| 指标 | 中文名称 | 测试前状态 | 主要衡量 |
|---|---|---|---|
p0 | 完全冷启动 | 无 lockfile、无 manifest 缓存、无 tarball/package store、无 node_modules | 首次安装时的依赖解析、网络请求、下载、解压和写入成本 |
p3 | 仅 lock 冷启动 | lockfile 已存在，但 tarball/package store 和 node_modules 被移除 | 已锁定依赖图后，在无包缓存时恢复依赖的能力 |
p4 | 热缓存安装 | lockfile 和 tarball/package store 已存在，仅移除 node_modules | 命中全局包缓存后，重建项目依赖目录的能力 |
不要使用“无 lockfile 但 manifest 缓存是热的”作为对比场景。Bun 会在短时间内保留较新的 manifest 且不重新校验，这个状态会让 Bun 获得不符合真实冷启动语义的额外优势。
poolab Linux · npmmirror 直连
- 日期：2026-07-21
- 项目：
ant-design - 环境：Linux x86_64 (poolab)
- 镜像源：
https://registry.npmmirror.com - 网络：直连，无
HTTP_PROXY、HTTPS_PROXY、NO_PROXY、npm proxy、macmini host entry 或 macmini shell 配置 - 版本：utoo 1.1.3、Bun 1.3.14、pnpm 10.34.5、aube 1.29.1
- 采样：
p0/p3各 3 轮交错采样，p45 轮交错采样
| 场景 | utoo | Bun | pnpm | aube |
|---|---|---|---|---|
完全冷启动 (p0) | 7.84s ± 2.17s | 13.21s ± 2.36s | 39.32s ± 16.56s | 27.63s ± 6.47s |
仅 lock 冷启动 (p3) | 6.64s ± 1.64s | 8.62s ± 3.57s | 15.14s ± 0.77s | 6.42s ± 0.31s |
热缓存安装 (p4) | 1.09s ± 0.05s | 2.72s ± 0.05s | 7.89s ± 0.38s | 1.60s ± 0.07s |
解读：
p0：utoo 是该环境中最快的完全冷启动结果，约为 Bun 耗时的 59%、pnpm 的 20%。p3：utoo 与 aube 的均值差异很小；9 轮配对复测后，utoo-minus-aube 的差值为 +0.214s，标准误为 0.506s，属于噪声范围，应视为基本持平。p4：utoo 的热缓存安装为 1.09s，明显快于 Bun、pnpm 和 aube。修正后的 pnpm warm run 网络接收约 4 KB，确认是有效的热缓存测量。
GitHub Actions · npmjs
- Harness branch/commit：
codex/aube-phase-benchmark/7a76aa3 - 项目：
ant-design - 镜像源：
https://registry.npmjs.org - 工作流：
https://github.com/utooland/utoo/actions/runs/29797404521 - 采样：
p0/p3各 3 轮交错采样，p45 轮交错采样 - aube：1.29.1，
trustPolicy: off
Linux (ubuntu-latest)
| 场景 | utoo | Bun | aube |
|---|---|---|---|
完全冷启动 (p0) | 8.13s ± 0.33s | 9.70s ± 0.24s | 17.54s ± 0.74s |
仅 lock 冷启动 (p3) | 7.22s ± 1.24s | 7.52s ± 0.04s | 8.37s ± 1.04s |
热缓存安装 (p4) | 2.25s ± 0.12s | 3.58s ± 0.05s | 2.59s ± 0.13s |
macOS (macos-latest, Apple Silicon)
| 场景 | utoo | Bun | aube |
|---|---|---|---|
完全冷启动 (p0) | 19.19s ± 2.43s | 22.81s ± 1.29s | 55.28s ± 5.78s |
仅 lock 冷启动 (p3) | 12.03s ± 0.53s | 15.58s ± 3.94s | 31.31s ± 3.12s |
热缓存安装 (p4) | 3.81s ± 0.19s | 5.37s ± 0.22s | 14.76s ± 0.26s |
原始 GitHub Actions 工作流有意省略 pnpm：ant-design 的 .npmrc 包含 package-lock=false，pnpm 10 将其映射为 lockfile=false，导致对应单元没有有效的 pnpm-lock.yaml，不能作为 p3 / p4 结果引用。
修正后的 pnpm 验证
- 加固后的 harness commit：
1e88fa2b - 工作流：
https://github.com/utooland/utoo/actions/runs/29809892297
| 平台 | 完全冷启动 (p0) | 仅 lock 冷启动 (p3) | 热缓存安装 (p4) |
|---|---|---|---|
| Linux | 26.20s ± 0.81s | 18.01s ± 1.03s | 7.19s ± 0.02s |
| macOS | 70.58s ± 13.74s | 57.25s ± 15.07s | 31.88s ± 2.58s |
Linux 的热缓存单元保留了约 1 MB 的 pnpm-lock.yaml 和约 1.45 GB 的 store，同时网络传输只有约 7 KB RX / 18 KB TX，确认这是有效的热缓存测量。同一轮也拒绝了 aube 的 p3 / p4，原因是缺少预期的 seeded lockfile，而不是继续记录陈旧状态的耗时。
测试口径
阶段化 harness 会为每个包管理器使用独立 store，恢复各自 lockfile，禁用生命周期脚本，并在不同轮次中交替包管理器执行顺序，减少网络波动和执行顺序对结果的影响。
测试还会记录网络流量，用于拒绝意外变冷的 warm 单元。例如 p4 应该主要复用已有 lockfile 和 tarball/package store；如果仍出现明显下载流量，就不能作为有效热缓存结果。
旧的 pm-bench-all 结果不应作为 utoo 与 Bun 的性能对比引用。该脚本的 warm 准备步骤会删除生成的 lockfile，但保留全局缓存，实际测量的是“热 manifest 缓存下的重新解析”，不符合这里的 p4 定义。