每个构建工具都只分析其自身的孤立环节。cargo build --timings 会告诉你 Cargo 构建过程没有问题。Ninja 的构建日志会显示链接阶段正常。然而，持续集成构建却耗时 22 分钟，且无人能指出时间究竟消耗在何处，因为这些工具彼此之间互不知晓对方的存在。
我开发了 buildline 来解决这个问题：它将各个构建工具已经生成的性能分析输出合并为一个统一的墙上时钟时间轴，并以标准的 Chrome 追踪事件格式 输出，因此可以直接在 Perfetto 中打开——无需构建或维护任何用户界面。
无人分析的空白地带
这是我在开始之前未曾预料到的部分。一个微小的 ninja 构建在不到一秒内完成。而一个真实的 cargo build 大约在 2.7 秒后才开始。没有任何工具自带的性能分析器记录下这段空白——Ninja 不知道 Cargo 的存在，而 Cargo 自身的计时器在启动瞬间从零开始。在合并后的时间轴上，这表现为明显的空白区域，而这正是真实持续集成日志中通常出现意外耗时的地方：工具链下载、依赖解析、环境设置等，所有这些对于每个工具自身的检测机制来说都是不可见的，因为它们发生在工具周围，而非内部。
这就是该项目的核心论点：在多工具构建中，真正的瓶颈往往位于工具之间的衔接处，而非任何一个工具内部。
如何避免成为脆弱的进程树黑客手段
“对由多个工具组成的构建进行性能分析”的显而易见的设计方案是一个编排器，它包裹整个构建过程，并以某种方式拦截其生成的每个子进程。我不希望这样做——进程拦截具有平台特异性，对于任何非直接子进程的情况（如容器、远程 shell、重新执行自身的构建系统）都非常脆弱，并且会将一个标准化工具变成一个 ptrace 项目。
buildline 改为包装每个工具的调用，并通过共享会话文件进行关联：
BUILDLINE_SESSION=./build.trace buildline -- ninja
BUILDLINE_SESSION=./build.trace buildline -- cargo build
# 在 <https://ui.perfetto.dev> 中打开 build.trace
每次调用都是透明的——继承标准输出和标准错误流，工具的真实退出代码原样传递。buildline 在执行被包装的命令之前立即打上墙上时钟时间戳，然后在工具退出后读取该工具自身的性能分析产物（.ninja_log、Cargo 的 --timings 报告），并将结果追加到共享追踪文件中。这里没有编排逻辑，没有进程树遍历，也没有最终处理步骤——在每次调用之后，build.trace 都是一个有效且可打开的 Chrome 追踪文件。
跨度结构体，以及最重要的设计决策
pub struct Span {
pub name: String, // "serde v1.0", "obj/parser.o"
pub category: Category, // 编译 | 链接 | 配置 | 解析 | 下载 | 测试 | 其他(字符串)
pub status: Status, // 成功 | 失败 | 跳过 | 未完成
pub track: String, // "cargo", "ninja" — 在 Perfetto 中对行进行分组
pub lane: u32, // 轨道内并行工作的子行
pub start_us: i64, // 相对于该工具自身的启动时间——此处无墙上时钟时间
pub dur_us: i64,
pub args: BTreeMap<String, String>,
}
每个适配器都是一个纯函数：输入原生工具输出，输出一个 Vec<Span>，时间戳相对于该工具自身的启动时间。包装器是唯一知晓墙上时钟时间的组件——它是一个薄层，将每个适配器的相对跨度偏移到共享轴上。将墙上时钟时间完全排除在适配器之外，使得黄金文件测试成为可能：适配器的输出
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
