Copying from GH (https://github.com/pantsbuild/pants/pull/23179#issuecomment-4305150634): --- Anecdotes from my testing this morning (unscientific, but I'll happily stand by the trends - not the exact numbers). Note: I already downloaded everything, so this is unrelated to networking.

bash
cargo build --release

default -> 1m 35s
debug = "line-tables-only" -> 1m 43s
codegen-units = 1 -> in 2m 43s
lto = "thin" -> 3m 09s
lto = "fat" -> 4m 19s

Excluding the debug aspect, each of the additive changes that increased build time, also generated a reliable, but incremental performance improvement on both

pants --version

and

pants --no-pantsd --version

... On my random, uncontrolled Mac Mini M2 Pro in my entirely typical development setup. Effectively, our startup time dropped very slightly. How this would look on other user's individual workloads... 🤷🏽 but in my experience with Pants, speeding up startup typically leads to same or slightly faster elsewhere speeds elsewhere as well. We run into a question of whether the juice is worth the squeeze at some point, but if it's CI juice we're squeezing, then even those incremental improvements spread across thousands of runs * people adds up. The thing I'm actually more interested in is whether we should have 3 profiles:

dev

(local runs),

release

(local runs),

release-lto

(runs in CI).

I'd like those big fat single file release binaries to be built with every ounce of compile time squeeze you can find to get the actual runtime perf as good as possible.

Yeah, me too. That's what I use locally (and panic abort - but I think we actually catch_unwind in our code, so I don't think we can use this - but I have to research a bit more about that). Difference is, most of my code is muuuuuch smaller and fewer dependencies, so when the build goes past 10 seconds, I get angry

I have no need for any debug info in release builds. If I'm debugging rust, it's always my local debug build

That's true. I was wondering about ensuring symbols were stripped, and stuff like that - but wasn't sure how much we use of that information from the field. In general, not much is my recollection

I do relatively little pure rust work and have -- at the moment -- a relatively beefy workstation. So I'm probably not in the right place to offer an opinion on exactly how things should be tuned for the local rust dev loop. I care that: • Release builds perform as well as possible. • Release builds have sufficient information to get backtraces, and the

perf

toolkit works. • The "default" should probably be something that makes sense for people working on src/python since that is the more common case. Three profiles makes sense to me. I was also (from the PR) fine with two. (My understanding is that "thin lto" is faster to do with a better result than "fat lto" and I'm curios if your results suggested otherwise.)

My understanding is that "thin lto" is faster to do with a better result than "fat lto" and I'm curios if your results suggested otherwise

Faster to build? Yeah. Better performance? I think that's a "it-depends", but there are cases where any LTO can slow one down (that's a bit of a degenerate case in my opinion). Overall, my experience with a bunch of projects has been that fat LTO runs faster than thin, but I can't claim that's a universal fact of life. When in doubt, I trust Nethercote (https://nnethercote.github.io/perf-book/build-configuration.html#link-time-optimization)