TL; DR: apply https://github.com/froydnj/gecko-dev/commit/12a80904837c60e2fc3c68295b79c42eb9be6650.patch 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: https://github.com/froydnj/gecko-dev/commit/12a80904837c60e2fc3c68295b79c42eb9be6650.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 https://github.com/rust-lang/cargo/issues/4380, 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. Thanks, -Nathan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform