Cargo 编译性能优化实战profile 分析 依赖裁剪 并行加速作为一个自学 Rust 的人我最大的痛点就是编译慢。第一次编译一个中型项目等了 8 分钟我甚至怀疑是不是电脑有问题。后来才知道Cargo 的编译慢不是偶然的——Rust 的类型系统、宏展开、codegen 单元都比其他语言更重。但这不代表没法优化。这篇就把我从 8 分钟编译优化到 2 分钟的实战过程完整写出来。一、为什么 Rust 编译慢——一个自学者的朴素拆解Rust 编译慢有几个根本原因宏展开derive(Deserialize)这种宏会在编译时生成大量代码展开后的代码量远超你写的。类型推导 单态化泛型函数对不同类型生成不同版本比如Veci32和VecString各有一份代码。serde的泛型特别多单态化后的代码膨胀很严重。LLVM 后端Rust 用 LLVM 做 codegenLLVM 对大量函数做优化很耗时。特别是 debug 模式下也会跑 LLVM 优化虽然级别低。我第一次 profile 编译时间时发现 serde 相关的 crate 占了总编译时间的 40%。这让我意识到编译优化不是加快编译器而是减少编译器要干的事。flowchart TD A[Cargo 编译慢] -- B[宏展开br/derive 大量生成代码] A -- C[单态化br/泛型膨胀] A -- D[LLVM codegenbr/优化耗时] B -- E[编译时间占比] C -- E D -- E E -- F[serde: 40%] E -- G[tokio: 15%] E -- H[项目代码: 20%] E -- I[其他依赖: 25%] style F fill:#f66 style G fill:#fc6二、profile 分析找出编译时间的真正瓶颈Cargo 自带编译时间统计但默认不开启。加上-Z timings标志需要 nightly可以看到每个 crate 的编译时间分布# 编译时输出每个 crate 的时间统计 cargo nightly build -Z timings # 生成的 HTML 报告会保存到 target/cargo-timings/ # 打开后可以看到 # - 每个 crate 的编译时间 # - 哪些 crate 之间有依赖关系影响并行度 # - codegen 单元的数量和耗时稳定版 Rust 也有一个实用的 flag--timings# 稳定版 Rust 的编译时间统计 cargo build --timings # 会在 target/cargo-timings/ 生成报告另外cargo build --verbose也能看出编译顺序# 查看编译顺序和每个 crate 的处理时间 cargo build --verbose 21 | grep Compiling # 输出类似 # Compiling serde v1.0.193 → 12.3s # Compiling serde_derive v1.0.193 → 8.7s # Compiling tokio v1.35.1 → 6.1s # Compiling my-project v0.1.0 → 3.2s我还用sccache来缓存编译结果特别是依赖 crate 的编译。第一次编译后后续只要依赖版本不变sccache 会直接用缓存# 安装 sccache cargo install sccache # 设置环境变量让 Cargo 使用 sccache export RUSTC_WRAPPERsccache # 第一次编译会正常慢但后续编译会快很多 cargo build # 查看缓存统计 sccache --show-stats # 输出类似 # Cache hits: 85/100 → 85% 缓存命中 # Cache misses: 15/100flowchart LR subgraph 无 sccache A1[每次全量编译br/依赖也要重编] -- A2[编译 8 分钟] end subgraph 有 sccache B1[依赖缓存命中 85%br/只编译项目代码] -- B2[编译 2 分钟] end A1 --|安装 sccache| B1 style A2 fill:#f66 style B2 fill:#6f6三、依赖裁剪砍掉没用到的功能和 crateCargo 的features机制是依赖裁剪的关键。很多 crate 默认开启一堆 features你可能只用了一小部分。比如 serde 默认开启std和derive但如果你只在no_std环境用stdfeature 就是多余的。实际操作# Cargo.toml 优化前后对比 # ❌ 优化前默认 features 全开 [dependencies] serde 1.0 tokio { version 1, features [full] } # full 包含所有 features reqwest 0.11 # 默认开启很多 features # ✅ 优化后只启用需要的 features [dependencies] serde { version 1.0, default-features false, features [derive] } # 只用 derive不需要 std如果项目已经依赖 std tokio { version 1, features [rt, macros, net] } # 只用 runtime macros net不需要 fs/process/io-util/signal/tracing 等 reqwest { version 0.11, default-features false, features [json, rustls-tls] } # 只用 json 解析 rustls TLS不用 default-tls(openssl) 和 cookies 等我还用cargo-udeps检查未使用的依赖# 安装 cargo-udeps需要 nightly cargo install cargo-udeps # 检查哪些依赖没有被代码实际引用 cargo nightly udeps # 输出类似 # warning: unused dependency: tempfile (specified in Cargo.toml but never imported) # warning: unused dependency: chrono (specified but only used in tests)裁剪依赖的实际效果很显著。我的项目优化前有 47 个依赖 crate裁剪后变成 23 个。编译时间从 8 分钟降到 5 分钟因为少了近一半的 crate 要编译。// ❌ 错误引用了整个 crate 但只用了很小一部分 use itertools; // 整个 itertools crate很多功能没用到 // ✅ 正确只引入需要的函数或者干脆不用重依赖 // 用标准库替代 itertools 的常用功能 fn flatten_nestedT(nested: VecVecT) - VecT { nested.into_iter().flatten().collect() // 标准库的 flatten 就够了 } fn zip_with_indexT(items: VecT) - Vec(usize, T) { items.into_iter().enumerate().collect() // 标准库的 enumerate 就够了 }graph TD A[项目依赖 47 个 crate] -- B[cargo-udeps 检查] B -- C[移除 12 个未使用依赖] B -- D[裁剪 12 个 crate 的多余 features] C -- E[剩余 23 个精简依赖] D -- E E -- F[编译时间: 8分钟 → 5分钟] style C fill:#6f6 style D fill:#6cf style F fill:#6f6四、并行加速codegen-unit 和 cargo 的并行编译Cargo 默认会并行编译不同的 crate没有依赖关系的 crate 可以同时编译。但单个 crate 内部的编译是串行的——LLVM 处理一个 crate 的所有函数没法拆成多线程。Rust 提供了codegen-units参数来解决这个问题把一个 crate 的代码拆成多个 unit每个 unit 独立编译可以并行。代价是拆 unit 会降低 LLVM 的跨函数优化效果。所以 release 模式默认codegen-units 1不拆最大化优化debug 模式默认codegen-units 16拆成16份加快编译。# Cargo.toml profile 配置 # release 模式编译速度 vs 运行性能的权衡 [profile.release] # 如果追求最快运行性能codegen-units 1默认 # 如果追求最快编译速度codegen-units 16牺牲约 5-10% 运行性能 codegen-units 4 # 折中4份并行编译快一些性能损失约2-3% # debug 模式默认就是 16不用改 # 本地开发用的 release-like profile编译快性能也还行 [profile.fast-release] inherits release # 继承 release 配置 codegen-units 16 # 最大并行 lto false # 不做跨 crate LTO大幅加快编译 opt-level 2 # 优化级别 2比 3 稍慢运行但编译快很多 # 生产发布用的正式 profile运行最快 [profile.production] inherits release codegen-units 1 # 不拆LLVM 全局优化 lto thin # thin LTO比 full LTO 快效果也不错 opt-level 3 # 最高优化级别使用不同 profile 编译# 开发阶段用 fast-release编译快 cargo build --profile fast-release # 生产发布用 production运行快 cargo build --profile production实测效果Profile编译时间运行性能适用场景dev (默认)8min基准本地调试fast-release2min比dev快约3x开发迭代release (默认)5min最快生产发布production7min比release快约5%极致性能thin LTO 的编译时间比 full LTO 短很多效果也接近。我推荐开发阶段不用 LTO发布阶段用 thin LTO。graph LR subgraph codegen-units 1 A1[LLVM 全局优化br/编译慢(5min)br/运行快] end subgraph codegen-units 4 A2[4份并行编译br/编译中(3min)br/运行稍慢2-3%] end subgraph codegen-units 16 A3[16份并行编译br/编译快(2min)br/运行慢5-10%] end A1 --|开发阶段| A3 A3 --|发布阶段| A1 style A1 fill:#6f6 style A3 fill:#6cf五、总结Cargo 编译优化不是什么神秘技巧核心思路就是减少编译器要干的事。我从 8 分钟降到 2 分钟做了四件事sccache 缓存依赖不变时缓存命中 85%省了最大的编译时间。安装和配置只需要两行命令。依赖裁剪用cargo-udeps找出未使用依赖用default-features false只启用需要的 features。crate 数量从 47 降到 23。codegen-units 调整开发阶段设为 16最快编译发布阶段设为 1最快运行。折中设为 4。LTO 策略开发阶段不做 LTO发布阶段用 thin LTO比 full LTO 快得多效果接近。我的建议顺序是先装 sccache最小成本最大收益再裁剪依赖收益稳定最后调 profile需要权衡编译速度和运行性能。别像我一开始那样看到编译慢就去调 profile结果调了半天发现瓶颈在依赖上——sccache 裁剪依赖才是真正的大头。作为的 Rust 学习者我最大的教训是编译慢不是你代码的问题是依赖和配置的问题。先 profile 再优化不要凭感觉乱调参数。cargo build --timings和cargo udeps这两个工具是我优化编译时间的照明灯——没有它们我就是在黑暗中摸索。完整配置和测试脚本在 GitHub有问题评论区讨论。编译慢是 Rust 的门槛但理解了原理之后优化起来并不难。
Cargo 编译性能优化实战profile 分析 依赖裁剪 并行加速作为一个自学 Rust 的人我最大的痛点就是编译慢。第一次编译一个中型项目等了 8 分钟我甚至怀疑是不是电脑有问题。后来才知道Cargo 的编译慢不是偶然的——Rust 的类型系统、宏展开、codegen 单元都比其他语言更重。但这不代表没法优化。这篇就把我从 8 分钟编译优化到 2 分钟的实战过程完整写出来。一、为什么 Rust 编译慢——一个自学者的朴素拆解Rust 编译慢有几个根本原因宏展开derive(Deserialize)这种宏会在编译时生成大量代码展开后的代码量远超你写的。类型推导 单态化泛型函数对不同类型生成不同版本比如Veci32和VecString各有一份代码。serde的泛型特别多单态化后的代码膨胀很严重。LLVM 后端Rust 用 LLVM 做 codegenLLVM 对大量函数做优化很耗时。特别是 debug 模式下也会跑 LLVM 优化虽然级别低。我第一次 profile 编译时间时发现 serde 相关的 crate 占了总编译时间的 40%。这让我意识到编译优化不是加快编译器而是减少编译器要干的事。flowchart TD A[Cargo 编译慢] -- B[宏展开br/derive 大量生成代码] A -- C[单态化br/泛型膨胀] A -- D[LLVM codegenbr/优化耗时] B -- E[编译时间占比] C -- E D -- E E -- F[serde: 40%] E -- G[tokio: 15%] E -- H[项目代码: 20%] E -- I[其他依赖: 25%] style F fill:#f66 style G fill:#fc6二、profile 分析找出编译时间的真正瓶颈Cargo 自带编译时间统计但默认不开启。加上-Z timings标志需要 nightly可以看到每个 crate 的编译时间分布# 编译时输出每个 crate 的时间统计 cargo nightly build -Z timings # 生成的 HTML 报告会保存到 target/cargo-timings/ # 打开后可以看到 # - 每个 crate 的编译时间 # - 哪些 crate 之间有依赖关系影响并行度 # - codegen 单元的数量和耗时稳定版 Rust 也有一个实用的 flag--timings# 稳定版 Rust 的编译时间统计 cargo build --timings # 会在 target/cargo-timings/ 生成报告另外cargo build --verbose也能看出编译顺序# 查看编译顺序和每个 crate 的处理时间 cargo build --verbose 21 | grep Compiling # 输出类似 # Compiling serde v1.0.193 → 12.3s # Compiling serde_derive v1.0.193 → 8.7s # Compiling tokio v1.35.1 → 6.1s # Compiling my-project v0.1.0 → 3.2s我还用sccache来缓存编译结果特别是依赖 crate 的编译。第一次编译后后续只要依赖版本不变sccache 会直接用缓存# 安装 sccache cargo install sccache # 设置环境变量让 Cargo 使用 sccache export RUSTC_WRAPPERsccache # 第一次编译会正常慢但后续编译会快很多 cargo build # 查看缓存统计 sccache --show-stats # 输出类似 # Cache hits: 85/100 → 85% 缓存命中 # Cache misses: 15/100flowchart LR subgraph 无 sccache A1[每次全量编译br/依赖也要重编] -- A2[编译 8 分钟] end subgraph 有 sccache B1[依赖缓存命中 85%br/只编译项目代码] -- B2[编译 2 分钟] end A1 --|安装 sccache| B1 style A2 fill:#f66 style B2 fill:#6f6三、依赖裁剪砍掉没用到的功能和 crateCargo 的features机制是依赖裁剪的关键。很多 crate 默认开启一堆 features你可能只用了一小部分。比如 serde 默认开启std和derive但如果你只在no_std环境用stdfeature 就是多余的。实际操作# Cargo.toml 优化前后对比 # ❌ 优化前默认 features 全开 [dependencies] serde 1.0 tokio { version 1, features [full] } # full 包含所有 features reqwest 0.11 # 默认开启很多 features # ✅ 优化后只启用需要的 features [dependencies] serde { version 1.0, default-features false, features [derive] } # 只用 derive不需要 std如果项目已经依赖 std tokio { version 1, features [rt, macros, net] } # 只用 runtime macros net不需要 fs/process/io-util/signal/tracing 等 reqwest { version 0.11, default-features false, features [json, rustls-tls] } # 只用 json 解析 rustls TLS不用 default-tls(openssl) 和 cookies 等我还用cargo-udeps检查未使用的依赖# 安装 cargo-udeps需要 nightly cargo install cargo-udeps # 检查哪些依赖没有被代码实际引用 cargo nightly udeps # 输出类似 # warning: unused dependency: tempfile (specified in Cargo.toml but never imported) # warning: unused dependency: chrono (specified but only used in tests)裁剪依赖的实际效果很显著。我的项目优化前有 47 个依赖 crate裁剪后变成 23 个。编译时间从 8 分钟降到 5 分钟因为少了近一半的 crate 要编译。// ❌ 错误引用了整个 crate 但只用了很小一部分 use itertools; // 整个 itertools crate很多功能没用到 // ✅ 正确只引入需要的函数或者干脆不用重依赖 // 用标准库替代 itertools 的常用功能 fn flatten_nestedT(nested: VecVecT) - VecT { nested.into_iter().flatten().collect() // 标准库的 flatten 就够了 } fn zip_with_indexT(items: VecT) - Vec(usize, T) { items.into_iter().enumerate().collect() // 标准库的 enumerate 就够了 }graph TD A[项目依赖 47 个 crate] -- B[cargo-udeps 检查] B -- C[移除 12 个未使用依赖] B -- D[裁剪 12 个 crate 的多余 features] C -- E[剩余 23 个精简依赖] D -- E E -- F[编译时间: 8分钟 → 5分钟] style C fill:#6f6 style D fill:#6cf style F fill:#6f6四、并行加速codegen-unit 和 cargo 的并行编译Cargo 默认会并行编译不同的 crate没有依赖关系的 crate 可以同时编译。但单个 crate 内部的编译是串行的——LLVM 处理一个 crate 的所有函数没法拆成多线程。Rust 提供了codegen-units参数来解决这个问题把一个 crate 的代码拆成多个 unit每个 unit 独立编译可以并行。代价是拆 unit 会降低 LLVM 的跨函数优化效果。所以 release 模式默认codegen-units 1不拆最大化优化debug 模式默认codegen-units 16拆成16份加快编译。# Cargo.toml profile 配置 # release 模式编译速度 vs 运行性能的权衡 [profile.release] # 如果追求最快运行性能codegen-units 1默认 # 如果追求最快编译速度codegen-units 16牺牲约 5-10% 运行性能 codegen-units 4 # 折中4份并行编译快一些性能损失约2-3% # debug 模式默认就是 16不用改 # 本地开发用的 release-like profile编译快性能也还行 [profile.fast-release] inherits release # 继承 release 配置 codegen-units 16 # 最大并行 lto false # 不做跨 crate LTO大幅加快编译 opt-level 2 # 优化级别 2比 3 稍慢运行但编译快很多 # 生产发布用的正式 profile运行最快 [profile.production] inherits release codegen-units 1 # 不拆LLVM 全局优化 lto thin # thin LTO比 full LTO 快效果也不错 opt-level 3 # 最高优化级别使用不同 profile 编译# 开发阶段用 fast-release编译快 cargo build --profile fast-release # 生产发布用 production运行快 cargo build --profile production实测效果Profile编译时间运行性能适用场景dev (默认)8min基准本地调试fast-release2min比dev快约3x开发迭代release (默认)5min最快生产发布production7min比release快约5%极致性能thin LTO 的编译时间比 full LTO 短很多效果也接近。我推荐开发阶段不用 LTO发布阶段用 thin LTO。graph LR subgraph codegen-units 1 A1[LLVM 全局优化br/编译慢(5min)br/运行快] end subgraph codegen-units 4 A2[4份并行编译br/编译中(3min)br/运行稍慢2-3%] end subgraph codegen-units 16 A3[16份并行编译br/编译快(2min)br/运行慢5-10%] end A1 --|开发阶段| A3 A3 --|发布阶段| A1 style A1 fill:#6f6 style A3 fill:#6cf五、总结Cargo 编译优化不是什么神秘技巧核心思路就是减少编译器要干的事。我从 8 分钟降到 2 分钟做了四件事sccache 缓存依赖不变时缓存命中 85%省了最大的编译时间。安装和配置只需要两行命令。依赖裁剪用cargo-udeps找出未使用依赖用default-features false只启用需要的 features。crate 数量从 47 降到 23。codegen-units 调整开发阶段设为 16最快编译发布阶段设为 1最快运行。折中设为 4。LTO 策略开发阶段不做 LTO发布阶段用 thin LTO比 full LTO 快得多效果接近。我的建议顺序是先装 sccache最小成本最大收益再裁剪依赖收益稳定最后调 profile需要权衡编译速度和运行性能。别像我一开始那样看到编译慢就去调 profile结果调了半天发现瓶颈在依赖上——sccache 裁剪依赖才是真正的大头。作为的 Rust 学习者我最大的教训是编译慢不是你代码的问题是依赖和配置的问题。先 profile 再优化不要凭感觉乱调参数。cargo build --timings和cargo udeps这两个工具是我优化编译时间的照明灯——没有它们我就是在黑暗中摸索。完整配置和测试脚本在 GitHub有问题评论区讨论。编译慢是 Rust 的门槛但理解了原理之后优化起来并不难。
