本文只保留同一个 PR 的两次成功门禁 A/B 数据：一次使用 RAM workspace，一次使用普通磁盘/容器 overlay workspace。其他历史构建不作为本文性能结论依据。
需要说明的是，本次被测 manifest PR 不携带组件源码变更，也没有进入组件编译路径，因此本文数据主要反映 manifest 聚合发布、环境切换、打包和大量临时文件 I/O 的收益。对于包含组件编译的门禁，RAM workspace 通常会覆盖更多中间文件和构建产物写入，收益预期会更明显；已有粗粒度观察显示这类场景提速至少可达到约 32% 以上，但尚未完成同 PR、同负载的细粒度 A/B 拆分，所以本文不把该数值作为严格结论。
对比对象
| 构建 | 节点形态 | workspace 形态 | 结果 |
|---|---|---|---|
| RAM 构建 | 高内存构建 VM | workspace 和 /tmp 挂载到 tmpfs |
SUCCESS |
| 普通构建 | 同类构建 VM | 仅挂载 /tmp，workspace 落在容器 overlay2 |
SUCCESS |
两次构建执行同一个 PR、同一个多板/多配置发布流程，因此可以直接对比。
构建内容说明
这不是一次简单编译，而是两套板卡/SDK 环境下的四次发布构建：
| 板卡口径 | SDK/环境口径 | 构建段 |
|---|---|---|
| 板卡 A | 25.12-1711 | 发布构建、debug/装备包构建 |
| 板卡 B | 25.12-1712 | 发布构建、debug/装备包构建 |
也就是说，主构建阶段内部实际执行了 4 次 publish：
-
板卡 A + 1711 SDK + 发布构建
-
板卡 A + 1711 SDK + debug/装备包构建
-
板卡 B + 1712 SDK + 发布构建
-
板卡 B + 1712 SDK + debug/装备包构建
因此本文数据代表“多板、多 SDK、多发布段”的 manifest 聚合构建，不应该和普通组件门禁的一次组件编译直接横比。
Stage 耗时
| 阶段 | RAM 构建 | 普通构建 | 差值 | 说明 |
|---|---|---|---|---|
| 总耗时 | 691290 ms | 899551 ms | -208261 ms | RAM 总耗时压缩到 76.8%，约 1.30x |
| 拉取镜像 & 启动容器 | 1449 ms | 13267 ms | -11818 ms | 非主要差异 |
| 初始化 SDK | 76486 ms | 71410 ms | +5076 ms | 基本同量级，SDK路径没有使用RAM |
| 准备源码 | 1093 ms | 14688 ms | -13595 ms | 普通构建重跑后为 14.7s，数据误差，参考平均6，7S |
| 解析构建配置 | 539 ms | 548 ms | -9 ms | 无明显差异 |
| 加载仓库配置 | 3859 ms | 3852 ms | +7 ms | 无明显差异 |
| 主构建阶段 | 596533 ms | 779440 ms | -182907 ms | 真实构建阶段压缩到 76.5%，约 1.31x |
| 环境预检 | 1779 ms | 1825 ms | -46 ms | 无明显差异 |
| 收集日志 | 580 ms | 843 ms | -263 ms | 非主要差异 |
| 回写报告 | 1729 ms | 1217 ms | +512 ms | 非主要差异 |
| Post 清理 | 4846 ms | 10377 ms | -5531 ms | RAM 清理路径更短 |
核心结论：
-
主构建阶段从 779.4s 降到 596.5s，减少 182.9s，提速约 1.31x。
-
端到端总耗时从 899.6s 降到 691.3s，减少 208.3s，提速约 1.30x。
-
源码准备阶段从 14.7s 降到 1.1s，绝对收益约 13.6s；它不是本文主要收益来源(理论上是误差失真，真实平均为6，7s)。
源码准备阶段说明
两次构建的准备源码脚本动作一致：写入 HTTPS git 凭据、clone 目标仓、fetch PR head、merge 出门禁工作树，并复制 CI 辅助脚本。
关键差异是 workspace 路径：
-
RAM 构建把 workspace 绑定到 tmpfs，源码 clone 和工作树写入内存盘。
-
普通构建没有给 workspace 做 bind mount，源码 clone 写入容器 overlay2。
重跑后，普通构建源码准备耗时为 14.7s，数据有失真，平均为6，7s；更准确的描述是：RAM workspace 能减少源码准备阶段的小文件写入开销，但主要收益仍来自主构建阶段的大量临时文件 I/O。
统一镜像与环境准备说明
本次内部验证还有一个项目特定背景：基础统一镜像是 26.03 基线，而被测分支实际需要收敛到 25.12 生效 SDK、工具链和依赖环境。该收敛过程由项目 manifest 中的 buildenv 扩展完成，会自动切换 SDK、Conan 仓、工具版本、证书吊销列表和全局工具目录。
这不是上游社区原生通用能力。
测试环境边界
本次测试运行在 QEMU/KVM 构建 VM 上：
-
宿主机 CPU：Intel Core i7-11700，8 core / 16 thread，内存约 78GiB。
-
构建 VM：12 vCPU，约 52GiB 固定内存，balloon 关闭。
-
QEMU cgroup 禁止 swap，Guest 内部也未开启 swap。
-
构建 VM 磁盘后端为 NVMe SSD，Guest 视角为 SSD 类虚拟磁盘。
-
RAM workspace 使用 36G tmpfs。
swap 优化边界是构建 VM：QEMU/cgroup 层禁止 swap，Guest 内不启用 swap，VM 固定内存并关闭 balloon。它不是通过关闭宿主机全局 swap 实现的。
建议
-
RAM workspace 适合加速大量临时文件、构建产物、压缩包、rootfs、签名文件等 workspace I/O。
-
不建议直接把 Docker data-root 整体迁入 RAM，风险和清理复杂度更高。
-
普通节点也可以考虑显式 bind mount 磁盘 workspace，避免源码准备阶段落在容器 overlay2。
-
后续监控应记录 tmpfs 峰值、overlay2 用时、Post 清理耗时，避免把偶发长尾当成稳定收益。