Let's talk about Link-Time Optimization (LTO)
summary
Practical findings: enabling LTO is one line in Cargo.toml; fat LTO gives noticeably smaller binaries compared to thin LTO but raises build time and memory (seen 17–30+ GB), while thin LTO is multi‑threaded and often faster. Combining LTO with codegen-units = 1 yields the biggest size and sometimes build‑time wins (one case 3 → 2 minutes). Cross‑language/linker LTO is fragile—LLVM versions and C/C++ undefined behavior commonly break it—so prefer LTO for Rust‑only code and benchmark per project.
AI-written summary · about
chapters (22)
- 0:00Link-Time Optimization intro
- 1:08LTO in Rust projects
- 3:34Compiler context with LTO
- 4:18Types of LTO in Rust
- 7:12Binary size with LTO
- 8:55Runtime performance impact
- 10:38Build time trade-offs
- 12:25Identical code folding limitations
- 13:08AI tools misunderstand LTO
- 15:18LTO and codegen units
- 16:43Cargo release defaults
- 17:49Dev vs production builds
- 18:55External optimization guidelines
- 20:16LTO in project templates
- 21:24Safety of LTO in Rust
- 22:51Cross-language LTO challenges
- 24:37LLVM compatibility issues
- 25:40Dev profile misconfigurations
- 26:21Thin vs fat LTO
- 27:47LTO and cryptography
- 28:07Enabling LTO guide
- 29:12Rust should adopt LTO
related talks
01h 02mThinLTO: Scalable and Incremental Link-Time Optimization
48mGCC Link Time Optimization and the Linux Kernel
23mChallenges with Kernels built with LTO
34mCode Size Compiler Optimizations and Techniques for Embedded Systems
43mRust Unlinked: Rustc, Symbols, and Static Libraries
52mDotty Linker: Precise Types Bring Performance
19mExploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the(…)
01h 04mJust-in-Time Compilation: The Next Big Thing?
