shrink the release by 25% with this one weird trick#10887
Conversation
iximeow
left a comment
iximeow
left a comment
There was a problem hiding this comment.
so.. on the expectation that your smoke testing this on a racklette turns out OK.. maybe probably OK? I was trying to remember where I'd gotten a bit of LTO allergy outside the most boring x86_64-unknown-linux target and https://rustc-dev-guide.rust-lang.org/building/optimized-build.html reminds me a bit.
we're at least also going through LLVM, instead of whatever's happening with MSVC over there, so that's a lot of points in favor of "it's probably fine".. but if LTO is actually not tested on x86_64-illumos-illumos at all that's not great (file under "we should make sure the rust-lang test suite runs on illumos ..)
my inclination is "I'd like as much time with these artifacts as we can before putting it in front of customers". at the very least if there's going to be weirdness I think checking that USDT probes in Nexus (or Oximeter? we really don't have any in sled-agent?!) still work wouldn't hurt too
|
Smoke tested on dublin. Control plane comes up and I can launch an instance, and USDT probes in Nexus still exist and are firing. Not a full test by any means but the obvious stuff seems to still function. |
|
I'm going to tag this for 23 because I think if we feel okay about this change I want to introduce it at the beginning of a release cycle so we're a lot more likely to catch any potential issues. |
2 participants
This enables "thin" LTO in the release profile. This drops the size of our TUF repos from ~2.8 GiB to ~2.1 GiB, savings of a little more than an entire CD-ROM.
Cargo's LTO settings are described at https://doc.rust-lang.org/cargo/reference/profiles.html#lto. The default is thin local LTO, which does not perform any LTO optimization across crates. We have lots of crate boundaries, so this probably isn't doing us a whole lot of good.
Build time impact seems to vary by crate. Nexus appears to take less time to build, but OMDB takes more. At the CI level it seems to all even out a bit, the package job is faster and the tuf-repo job is a tad bit slower.