第28章 报告构建耗时

--timings 选项提供每次编译耗时的相关信息，并追踪随时间变化的并发情况。

cargo build --timings

该命令会在 target/cargo-timings/cargo-timing.html 生成一份 HTML 报告。同时，它还会在同一目录下生成一份带时间戳的报告副本，方便你查看历史运行记录。

解读图表

输出中包含两个表格和两个图表。

第一个表格显示项目的构建信息，包括构建的单元数量、最大并发数、构建耗时以及当前所用编译器的版本信息。

“unit” 图表展示了每个单元随时间推移的持续时间。这里的“单元”指单次编译器调用。图中连线指示了某个单元完成后，哪些附加单元会被“解除阻塞”。也就是说，它展示了因依赖项已全部完成而获准运行的新单元。将鼠标悬停在单元上即可高亮相关连线，有助于可视化依赖关系中的关键路径。由于单元完成的顺序可能不同，此路径在不同运行中可能会发生变化。

“codegen” 阶段的时间以淡紫色高亮显示。在某些情况下，构建流水线允许在依赖项进行代码生成时就开始下一个单元。这种信息并非总是显示（例如，二进制单元不显示代码生成的开始时间）。

“custom build” 单元即 build.rs 脚本，运行时会以橙色高亮。

第二个图表展示了 Cargo 随时间变化的并发情况。背景代表 CPU 使用率。三条线分别表示：

• “Waiting”（红色）—— 等待 CPU 槽位空出来的单元数量。
• “Inactive”（蓝色）—— 等待依赖项完成的单元数量。
• “Active”（绿色）—— 当前正在运行的单元数量。

注意：这并不展示编译器内部的并发情况。rustc 通过“job server”与 Cargo 协调，以确保在并发限制内运行。目前这一机制主要适用于代码生成阶段。

以下是缩短编译时间的几点建议：

• 找出耗时的依赖。
  • 检查它们是否包含一些可以考虑禁用的 features。
  • 考虑干脆移除这个依赖。
• 查看是否有 crate 以不同版本被多次编译。尝试从依赖图中移除旧版本。
• 把过大的 crate 拆分成更小的模块。
• 如果大量 crate 都卡在同一个 crate 上，应集中精力优化那一个 crate，以提升并行度。

最后一张表列出了每个编译单元（unit）的总耗时和“codegen”耗时，以及编译各单元时启用的 features。