TL; DR: apply
to get faster --enable-optimize local builds if you are working on
Stylo or touching Rust in any way.  Please try to not commit it along
with your regular patches. =D

You may have noticed that Rust compile times for --enable-optimize
builds have gotten worse lately.  This is partly due to the large
amount of Rust code we now have (with more on the way, surely), but
also because our Rust code builds with Rust's link-time optimization
(LTO) for such builds.  Building our Rust code this way makes our
binaries smaller, but imposes significant compile-time costs.

Bug 1386371 is open to track disabling LTO in Rust code on
non-automation builds, but in the absence of a solution there, I have
written a patch:

which you can apply in your local repository.  Having local patches is
obviously not optimal, as there's a risk that they will be committed
accidentally, but it's probably the best solution we have right now.

I know you have suggestions and/or questions, so let's transition to a
Q&A format:

Q: This patch is great, my compile is as fast as a photon!  Why don't
we just commit the patch?

A: Compiling without LTO imposes significant binary size costs.  We
don't have a great way to leave LTO disabled for local builds, but
enable it for automation builds.

Q: We can pass in flags to rustc via `RUSTFLAGS`: we can set
RUSTFLAGS="-C lto" for automation builds!  Why not do that?

A: Because rustc complains about compiling all of our intermediate
rlibs with `-C lto`.

Q: Ugh.  Could we fix rustc to not complain?

A: rustc's behavior here, while reasonable, is certainly fixable.
This or the Cargo modifications, below, are feasible options for
fixing things.

Q: Why modify Cargo?  We could run our Cargo.toml files through a
preprocessor before passing them to `cargo`, setting `lto`
appropriately for the style of build we're doing.  Wouldn't that work?

A: The output of the preprocessed Cargo.toml would then live in the
objdir, which wouldn't play well with Cargo.lock files.  Upgrading
Rust packages would require a complicated dance as well, which in turn
would affect things like the servo syncing service on autoland.

Q: What if we put the generated Cargo.toml in the srcdir instead?

A: This idea is sort of feasible, but then the build process is
modifying the srcdir, which is far from ideal: we have actively fixed
instances of this happening in the past.  Upgrading packages would
also be a pain, for similar reasons as the previous question.

Q: Huh.  OK, so what are we doing?

A: The current idea, courtesy of glandium, is to add command-line
flags to Cargo to permit setting or overriding of arbitrary Cargo.toml
settings, and then add the appropriate flags to our Cargo invocations.
An initial implementation of this idea lives in, though there were
concerns expressed that this functionality might be a little
over-the-top for what we want to do, and making rustc stop complaining
(see above) might be a better fix.

Whichever fix we did--rustc or Cargo or maybe even both!--we'd need to
build in automation with newer versions of the appropriate tool, and
we'd need to ensure that local builds *didn't* use the options.  Both
of these solutions are reasonably simple, and it is entirely possible
that we could have the fix uplifted to beta Rust and therefore have
the fix available for the 1.20 release, which we're planning on using
to build 57.

dev-platform mailing list

Reply via email to