把编译时间摊在一条时间线上:开源构建追踪工具 buildprof
来源: lalitm.com — 2026-09-12
概述
作者 Lalit Maganti 做了开源追踪工具 buildprof,用来回答「构建的时间到底花在哪」。用法极简,把它放在任何既有构建命令前面就行:buildprof -- cargo build 会记录该命令启动的每一个进程及其子进程,按时间轴从左到右排开,条形宽度表示耗时,子进程挂在启动它的父进程下方。动机来自 Bun 首席架构师 Jarred Sumner 那条「新的 Rust 构建在 Linux 上比旧 Zig 构建快 5 倍以上」的推文:作者凭经验认为同规模 Zig 项目通常比 Rust 编译更快,于是决定复现。他用脚本在 6 核 12 线程的 Linux 虚拟机上重放 Bun 1.3.14(Zig 时代)与 1.4.0(Rust 时代)的 CI 构建,得到 24 分 24 秒对 5 分 40 秒,与官方 CI 中位数 30 分 06 秒对 5 分 37 秒大致吻合。他认为推文一笔带过的 Full LTO 与 ThinLTO 差异很可能是关键变量,并把优化阶段与 JavaScriptCore 符号等环节逐个摊开来看。
核心要点
- 用法是无侵入前缀:buildprof -- make -j16 / cargo build / ninja 都能用,不必改构建脚本。
- 它记录整棵进程树并排在一条时间轴上,宽度即耗时,子进程挂在父进程下方。
- 起因是 Bun 那条「Rust 比 Zig 快 5 倍」的推文,作者复现后确认差距真实存在:24 分 24 秒对 5 分 40 秒。
- 被推文一笔带过的 Full LTO 与 ThinLTO 差异被他列为最可疑的变量之一。
- 他同时提醒不能把省下的每一秒都归功于 LTO 设置,因为并没有重建同规格的 Full-LTO WebKit 归档做对照。
- 目前 buildprof 支持 Clang、LLD 与 nightly Rust 的编译器追踪,依赖 eBPF/ftrace/ptrace 等追踪能力。
金句
有时候构建慢只是因为代码量大,但更多时候,问题是可修的。
👍 0
👎 0
返回 Lobsters 首页