Skip to content

Commit f035408

Browse files
committed
cargo: straighten out LTO configuration
This PR tweaks the change made in #5904 so that the `profiling` Cargo profile does _not_ have LTO enabled. With LTO enabled, compile times even after just doing a `touch crates/uv/src/bin/uv.rs` are devastating: $ cargo b --profile profiling -p uv Compiling uv-cli v0.0.1 (/home/andrew/astral/uv/crates/uv-cli) Compiling uv v0.2.34 (/home/andrew/astral/uv/crates/uv) Finished `profiling` profile [optimized + debuginfo] target(s) in 3m 47s Even with `lto = "thin"`, compile times are not great, but an improvement: $ cargo b --profile profiling -p uv Compiling uv v0.2.34 (/home/andrew/astral/uv/crates/uv) Finished `profiling` profile [optimized + debuginfo] target(s) in 53.98s But our original configuration for `profiling`, prior to #5904, was with LTO completely disabled: $ cargo b --profile profiling -p uv Compiling uv v0.2.34 (/home/andrew/astral/uv/crates/uv) Finished `profiling` profile [optimized + debuginfo] target(s) in 30.09s This gives reasonable-ish compile times, although I still want them to be better. This setup does risk that we are measuring something in benchmarks that we are shipping, but in order to make those two the same, we'd either need to make compile times way worse for development, or take a hit to binary size and a slight hit to runtime performance in our release builds. I would weakly prefer that we accept the hit to runtime performance and binary size in order to bring our measurements in line with what we ship, but I _strongly_ feel that we should not have compile times exceeding minutes for development. When doing performance testing, long compile times, for me anyway, break "flow" state. A confounding factor here was that #5904 enabled LTO for the `release` profile, but the `dist` profile (used by `cargo dist`) was still setting it to `lto = "thin"`. However, because of shenanigans in our release pipeline, we we actually using the `release` profile for binaries we ship. This PR does not make any changes here other than to remove `lto = "thin"` from the `dist` profile to make the fact that they are the same a bit clearer. cc @davfsa
1 parent eed23be commit f035408

File tree

1 file changed

+39
-3
lines changed

1 file changed

+39
-3
lines changed

Cargo.toml

Lines changed: 39 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -205,12 +205,49 @@ rest_pat_in_fully_bound_structs = "warn"
205205

206206
[profile.release]
207207
strip = true
208-
lto = true
208+
lto = "fat"
209209

210+
# This profile is meant to mimic the `release` profile as closely as
211+
# possible, but using settings that are more beneficial for iterative
212+
# development. That is, the `release` profile is intended for actually
213+
# building the release, where as `profiling` is meant for building `uv`
214+
# for running benchmarks.
215+
#
216+
# The main differences here are to avoid stripping debug information
217+
# and disabling lto. This does result in a mismatch between our release
218+
# configuration and our benchmarking configuration, which is unfortunate.
219+
# But compile times with `lto = true` are completely untenable:
220+
#
221+
# $ cargo b --profile profiling -p uv
222+
# Compiling uv-cli v0.0.1 (/home/andrew/astral/uv/crates/uv-cli)
223+
# Compiling uv v0.2.34 (/home/andrew/astral/uv/crates/uv)
224+
# Finished `profiling` profile [optimized + debuginfo] target(s) in 3m 47s
225+
#
226+
# Using `lto = "thin"` brings a massive improvement, but it's still slow:
227+
#
228+
# $ cargo b --profile profiling -p uv
229+
# Compiling uv v0.2.34 (/home/andrew/astral/uv/crates/uv)
230+
# Finished `profiling` profile [optimized + debuginfo] target(s) in 53.98s
231+
#
232+
# But with `lto = false`:
233+
#
234+
# $ cargo b --profile profiling -p uv
235+
# Compiling uv v0.2.34 (/home/andrew/astral/uv/crates/uv)
236+
# Finished `profiling` profile [optimized + debuginfo] target(s) in 30.09s
237+
#
238+
# We get more reasonable-ish compile times. At least, it's not enough
239+
# time to get up and get a cup of coffee before it completes.
240+
#
241+
# This setup does risk that we are measuring something in benchmarks
242+
# that we are shipping, but in order to make those two the same, we'd
243+
# either need to make compile times way worse for development, or take
244+
# a hit to binary size and a slight hit to runtime performance in our
245+
# release builds.
210246
[profile.profiling]
211247
inherits = "release"
212248
strip = false
213-
debug = true
249+
debug = "full"
250+
lto = false
214251

215252
[profile.fast-build]
216253
inherits = "dev"
@@ -220,7 +257,6 @@ strip = "debuginfo"
220257
# The profile that 'cargo dist' will build with.
221258
[profile.dist]
222259
inherits = "release"
223-
lto = "thin"
224260

225261
# Config for 'cargo dist'
226262
[workspace.metadata.dist]

0 commit comments

Comments
 (0)