报告构建时间

--timings 选项提供了一些关于每个编译阶段耗时的信息，并跟踪了随时间推移的并发信息。

cargo build --timings

该选项会在 target/cargo-timings/cargo-timing.html 中生成一份 HTML 格式的报告。同时，它还会将报告的副本保存到同一目录下，并在文件名中添加时间戳，以便您查看之前的运行情况。

解读图表

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

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

build-info

“单元”图表展示了每个单元随时间推移的持续时间。一个“单元”代表一次编译器调用。图中的线条展示了当一个单元完成时，哪些额外的单元被“解锁”。也就是说，它展示了由于其依赖项已全部完成而现在允许运行的新单元。将鼠标悬停在某个单元上可以高亮显示相关的线条。这有助于可视化依赖项的关键路径。由于单元完成的顺序可能不同，因此该图表在不同的运行中可能会有所变化。

“代码生成”时间以淡紫色高亮显示。在某些情况下，构建流水线允许单元在其依赖项执行代码生成时就开始运行。此信息并不总是显示（例如，二进制单元不会显示代码生成何时开始）。

“自定义构建”单元是 build.rs 脚本，当它们运行时会以橙色高亮显示。

build-unit-time

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

  • “等待中”（红色）——表示正在等待 CPU 资源的单元数量。
  • “非活动”（蓝色）——表示正在等待其依赖项完成的单元数量。
  • “活动”（绿色）——表示当前正在运行的单元数量。

cargo-concurrency-over-time

注意：这并没有显示编译器本身的并发情况。rustc 通过“作业服务器”与 Cargo 进行协调，以保持在并发限制范围内。目前，这主要适用于代码生成阶段。

解决编译时间问题的技巧

  • 查找速度较慢的依赖项。
    • 检查它们是否具有您可能希望考虑禁用的功能。
    • 考虑尝试完全移除该依赖项。
  • 查找使用不同版本多次构建的箱子。尝试从依赖图中移除旧版本。
  • 将大型箱子拆分成较小的部分。
  • 如果大量箱子都依赖于同一个箱子，则应集中精力优化该箱子以提高并行度。

最后一个表格列出了每个单元的总耗时和“代码生成”时间，以及每个单元编译期间启用的功能。