docs: clarify local LTO guidance#7400
Conversation
github-actions
Bot
added
the
documentation
wjones127
left a comment
wjones127
left a comment
There was a problem hiding this comment.
I agree local development and testing don't need LTO. But I'm skeptical that turning it off for profiling in general is a good idea; it makes a meaningful difference in performance, which is the exact thing we are trying to measure in those builds. It would be like turning off SIMD during benchmarking—we'd be measuring the wrong thing.
Now, there are likely some benchmarks that aren't sensitive to LTO: if you are benchmarking IO-bound code, it's probably not necessary. But if you are doing CPU-bound benchmarks, such as distance function work, I would say keep the LTO on. Perhaps we can provide a guideline like that in the AGENTS.md?
| * Coverage: `cargo +nightly llvm-cov -q -p <crate> --branch` | ||
| * Coverage HTML: `cargo +nightly llvm-cov -q -p <crate> --branch --html` | ||
| * Coverage for file: `python ci/coverage.py -p <crate> -f <file_path>` | ||
| * Do not enable LTO for local development, debugging, or performance testing. Keep LTO reserved for explicitly requested release artifact validation. |
There was a problem hiding this comment.
question: why provide this guidance, instead of baking in profiles that specify LTO, and telling the agent to use those profiles? As-is, the agent has to figure out what profiles there are and modify them in order to comply with this guidance.
2 participants
This clarifies the repository agent instructions for Rust local workflows.
Local development, debugging, and performance testing should avoid LTO so those workflows do not accidentally pay release-artifact build costs or benchmark a build mode that was not explicitly requested. LTO remains available when release artifact validation explicitly asks for it.