DropGuard 内联代价与 Rust 构建机性价比

本期检索说明

先读取 content/collections/deep-radar 中截至 2026-08-31 的原文链接，并按 URL、标题和技术问题语义去重。最近 24 小时内最终只有 2 篇 Rust 材料同时具备实测、源码证据、原理解释和工程迁移价值，因此没有用发布说明或旧材料凑数。Java/OpenJDK 的 G1 evacuation-budget 补丁虽有完整源码与算法解释，但公开材料仅列出 Mach5 Tier 1–3 正确性测试，缺少性能或 evacuation-failure 变化数据，未达到本栏实测门槛；Kotlin、Zig 与 Linux 本周期也没有达到全部硬门槛的新增资料。

两项修改都仍处于公开评审阶段，本文分析的是已有源码、CI 与 benchmark 的提案，不把它们写成已合入版本的既成事实。

01 · Rust：一个 #[inline] 为什么救不回所有 DropGuard 回归

原文与日期： GrigorenkoPV，2026-08-31（中原标准时间）；为通用 DropGuard::drop 添加 #[inline] 的 PR #162064 与只回退原本带内联提示调用点的 PR #162067。回归来源与设计背景见将标准库局部 guard 统一为 mem::DropGuard 的 PR #161702。

为什么值得读： 这是一个很少见的同基线 A/B 修复实验。原改造把 BTree、VecDeque::Drain、slice clone 等位置手写的局部 guard 收敛为一个通用类型，源码明显减少，却同时擦掉了若干局部 Drop::drop 上的 #[inline]。两份补丁在同一个父提交上分别测试“给公共实现统一内联”和“只恢复三个性能敏感的局部实现”，把抽象复用、代码生成、编译器自身吞吐和二进制体积之间的冲突完整暴露出来。

核心技术结论： DropGuard<T, F> 的语义抽象没有问题：它用 ManuallyDrop::take 取出值，再调用一次 FnOnce(T)，保证正常退出和展开路径都执行清理。问题在于 LLVM 是否能在每个单态化调用点看穿这层通用 Drop。补丁 #162064 只增加一行：

const impl<T, F> Drop for DropGuard<T, F>
where
    F: [const] FnOnce(T),
{
    #[inline]
    fn drop(&mut self) {
        let inner = unsafe { ManuallyDrop::take(&mut self.inner) };
        (inner.1)(inner.0);
    }
}

它扩大了跨调用点内联机会，但这是全局提示：会改变所有实例的 IR 展开和后续优化，不保证每个 workload 都受益。#162067 的策略更保守，只在 BTree key/value drop、VecDeque::Drain 和 slice clone 三处恢复原来的局部 guard；这些实现原本就带 #[inline]，因此把优化决策重新放回具有具体字段、分支和内存移动上下文的调用点。

最有价值的实验、源码与 benchmark 细节： 两个 try build 使用相同父提交 45f215f，rustc-perf 以 instructions:u 作为主要指标。全局 #[inline] 方案在 primary benchmark 中有 5 个改善，均值 -0.4%、范围 -0.7% 至 -0.2%；同时仍有 2 个回退，均值 +0.9%、最差 +1.5%。其 bootstrap 从 475.395s 降至 473.906s（-0.31%），编译产物从 401.38 MiB 降至 400.48 MiB（-0.22%），但两个 primary Max RSS 回退均值为 +2.6%。

局部回退方案覆盖面更大：25 个 primary instruction benchmark 改善，均值 -0.5%、最好 -1.6%；同样残留 2 个 primary 回退，均值 +0.9%、最差 +1.5%。它的 bootstrap 仅改善 0.08%，链接二进制体积总体改善 1.1%，但完整 artifact 反而从 401.38 MiB 增至 402.63 MiB（+0.31%）；Max RSS 也同时出现 -7.6% 的单项改善与 +2.8% 至 +3.4% 的两个回退。两种方案都被机器人判为“regressions and improvements”，说明一行内联提示不能被简化成无条件修复，局部回退也没有消除全部负项。

适合的工程师背景： 维护 Rust/LLVM 编译器、泛型容器、RAII/异常安全 guard，或正在评估把多个手写热路径抽象成统一库组件的工程师。

预计阅读收益： 约 30–40 分钟；最可迁移的方法是为抽象重构保留修改前基线，使用同一父提交跑“全局内联”和“热点局部化”两个方案，并同时查看指令数、RSS、链接体积和完整 artifact，而不是用源码行数或单个 microbenchmark 决策。

02 · Rust CI：AArch64 构建从 145 分钟缩到 90 分钟，同时每次省 71%

原文与日期： Mark-Simulacrum，2026-08-31（中原标准时间）；rust-lang/rust PR #162063。实例迁移的早期实验、隔离模型与逐次 Actions 记录见 rust-lang/simpleinfra issue #1132。

为什么值得读： 文章价值不在“换一台更快的机器”，而在同一编译任务上同时测量完整发行构建、quick try build、x86_64 与 AArch64，并把墙钟时间换算成按次成本。最终选择也没有机械追求最快或最低价，而是根据 CI 关键路径为 full/quick 分别挑不同实例。

核心技术结论： full AArch64 构建选 m9g.2xlarge：8 vCPU 的内存型实例虽然不是最快，却以 90 分钟、$0.59/次替代当前 GHA 8-core 的 145 分钟、$2.03/次。quick build 选 c9g.4xlarge 而不是更便宜的 m9g.2xlarge，用每次多约 $0.126 换取 17 分钟延迟下降，因为 try job 位于开发反馈回路。x86_64 full 则从 32 vCPU c8a.8xlarge 下调为 16 vCPU c8a.4xlarge：构建增加 11 分钟，但成本从 $2.64 降至 $1.51。

源码配置把决策落到可审计的 runner identity，而不只停留在表格：

- &job-linux-aarch64-8c-ec2
  os: ec2-arm64ami-m9g.2xlarge-aarch64-linux-$github.run_id-$github.run_attempt

- &job-linux-aarch64-16c-ec2
  os: ec2-arm64ami-c9g.4xlarge-aarch64-linux-$github.run_id-$github.run_attempt

dist-aarch64-linux-quick 还显式设置 DIST_TRY_BUILD: 1；这顺手修复了按名称点选 quick job 时实际未进入 quick 模式的配置缺口。

最有价值的实验、源码与 benchmark 细节： full AArch64 的五组数据为：GHA 8c 145 分钟/$2.03，c8g.8xl 80 分钟/$1.69，c9g.8xl 60 分钟/$1.38，c9g.4xl 70 分钟/$0.81，m9g.2xl 90 分钟/$0.59。选中方案相对现状把时间降低约 37.9%，单次成本降低约 70.9%。

quick AArch64 的四组结果为 c8g.8xl 50 分钟/$1.059、c9g.8xl 40 分钟/$0.924、c9g.4xl 47 分钟/$0.543、m9g.2xl 64 分钟/$0.417；选 c9g.4xl 表明愿意比最低成本多付约 30%，换取约 26.6% 的延迟下降。x86 full 从 94 分钟/$2.64 改为 105 分钟/$1.51，成本下降约 42.8%，而更便宜的 m8a.2xl 要 130 分钟。PR 还附两次真实 try workflow，分别覆盖默认 quick 组合与显式请求的 full/quick × x86/AArch64 矩阵。

适合的工程师背景： 维护大型编译器、跨架构发行流水线、自托管 GitHub Actions runner，或需要把云实例规格转化为 CI 吞吐/成本 SLO 的基础设施工程师。

预计阅读收益： 约 20–30 分钟；可以直接迁移一套选型框架：为 full 与 quick 分开定义目标函数，固定构建产物与 AMI 后扫实例族，记录墙钟时间、按次成本及关键路径，并把选中的实例与 quick/full 开关一同固化到版本化配置。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-08-02 至 2026-09-01，单位人民币。截至本期截稿，尚未取得六个代表 SKU 的新同口径公开成交记录，因此沿用最近可复核的 8 月 25–26 日快照；没有把抓取日期冒充变价日期，也没有插值补齐逐日行情。下图六个面板分别对应 CPU、GPU、主板、DRAM、HDD、SSD，每一折点均为公开可追溯的实际报价。

零售价格来源： 9800X3D 与 9850X3D 国内同日价差、9800X3D 历史价格摘要、RTX 5070 商品百科、B850M 商品百科、8 月 26 日 B850M 市场样本、Kingston Fury 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。

判断依据

经济日报 8 月 14 日的华强北走访记录了 7 月 24 日起显卡快速拉涨、7 月 27 日后高位趋稳：RTX 5060 从约 ¥2,300–2,500 升至约 ¥3,000，RTX 5070 Ti 从约 ¥6,000 升至 ¥8,000 以上。这与跟踪样本的后段抬升一致，因此 GPU 仍建议观望，而不是把“涨幅收窄”解释为降价。

存储侧最近可核验的闪存市场现货报价中多种 TLC/QLC NAND 与 DDR5 UDIMM 渠道参考价持平。该渠道美元价不进入中国 ToC 折线，但它尚未提供持续下跌的供应侧信号。CPU 建议仍基于同平台新旧型号的即时价差；主板跨品牌促销差异已经大于短期时间趋势，适合按功能购买。

其它你可能关心的

• OpenJDK：G1 同时以暂停时间与复制字节预算选择 collection set

本期结论

这两篇材料都提醒我们不要用单一指标替代系统目标。DropGuard 重构减少重复源码，却改变了单态化与内联边界；全局一行 #[inline] 能改善整体均值，仍会留下局部指令与内存回退。CI 实例选型同样不是核数越多越好：full build 更看重每次成本，quick build 更看重反馈延迟，因此相同架构需要不同规格。可迁移的做法是保留同基线、多指标和真实工作负载，让抽象或基础设施决策接受完整结果矩阵，而不是只展示最好看的数字。