报告构建时间

--timings 选项会提供关于每次编译耗时的信息，并跟踪随时间变化的并发信息。

cargo build --timings

这会在 target/cargo-timings/cargo-timing.html 中写入一个 HTML 报告。如果您想查看旧的运行结果，这也会将报告副本写入到同一目录，并在文件名中包含时间戳。

阅读图表

输出中有两个表格和两个图表。

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

build-info

“单元”图表显示每个单元随时间的持续时间。“单元”是单个编译器调用。有一些线条显示当一个单元完成时，哪些额外的单元被“解锁”。也就是说，它显示了由于其依赖项都已完成，现在允许运行的新单元。将鼠标悬停在一个单元上以突出显示线条。这有助于可视化依赖项的关键路径。这可能会在不同运行之间发生变化，因为单元可能会以不同的顺序完成。

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

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

build-unit-time

第二个图表显示 Cargo 随时间的并发性。背景表示 CPU 使用率。三条线分别是：

  • “等待”（红色）— 这是等待 CPU 插槽打开的单元数量。
  • “非活动”（蓝色）— 这是等待其依赖项完成的单元数量。
  • “活动”（绿色）— 这是当前正在运行的单元数量。

cargo-concurrency-over-time

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

解决编译时间的技巧

  • 查找慢速依赖项。
    • 检查它们是否有您可能希望禁用 的功能。
    • 考虑尝试完全删除依赖项。
  • 查找以不同版本多次构建的 crate。尝试从依赖关系图中删除较旧的版本。
  • 将大型 crate 分割成更小的部分。
  • 如果大量 crate 受限于单个 crate，请将注意力集中在改进该 crate 上，以提高并行性。

最后一个表列出了每个单元的总时间和花费在“codegen”上的时间，以及每个单元编译期间启用的功能。