Description
We keep track of our code size on Android to keep our overall download size down. In updating our pinned nightly compiler (from nightly-2024-06-21; we're due for it), our CI turned up a code size increase of ~120KB in a library that's overall about 4.6MB—not huge, but not expected either. Bisecting on Rust toolchains turned up that the regression was introduced in nightly-2024-09-01 (as in, nightly-2024-08-30 does not have this extra code size, and there was no nightly-2024-08-31), and moreover I discovered that using -Zbuild-std recovered the additional code size. So something changed in how the prebuilt standard library is built, in a way that may not have been intended.
Unfortunately, our Android build process does a whole bunch of work at once, so I don't have a minimal example for you. My reproduction has been
- Install the Android NDK (27.0.12077973 is the one we're currently using)
- Check out https://github.com/signalapp/libsignal/releases/tag/v0.57.1
ANDROID_NDK_HOME=path/to/ndk/27.0.12077973 java/build_jni.sh android-arm64
- Save the resulting library, then repeat with
RUSTUP_TOOLCHAIN=nightly-2024-09-01
. - Compare the libraries' post-stripped sizes, or use a tool like
bloaty
to measure VM size only
It's possible this change was expected, in which case please close the issue; I understand code sizes go up sometimes!
@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged
Activity
RalfJung commentedon Sep 13, 2024
Thanks for the report!
Any chance you could try to bisect this further using cargo-bisect-rustc? Since this is recent enough, that should be able to narrow it down to a single PR.
jrose-signal commentedon Sep 13, 2024
It took a bit to get it right, and I'm still not sure I got it entirely correctly, but here's the tail end of the output!
Of the commits in 9649706, #129640 is my personal bet…
My detection script could also be off, I used
test "$(du "$lib"| cut -f1)" -lt 9300
as the "good" case (the full jump was 9168 du-blocks to 9408).workingjubilee commentedon Sep 13, 2024
@jrose-signal Does this affect the size of any completed binaries you use?
jrose-signal commentedon Sep 13, 2024
Yes, the .so being measured here is the aarch64 slice of libsignal, as shipped in our Android app.
workingjubilee commentedon Sep 13, 2024
Oh, okay!
@jrose-signal Actually, I think the commit at fault is likely to be #129642 because now Android is getting the backtrace code linked in All The Time.
It's either that, the PR you noticed, or #129366 which changes linkage.
jrose-signal commentedon Sep 13, 2024
Ah, backtraces. >< That might explain why -Zbuild-std helps so much, last time I measured the most expensive part of backtrace support is resolving symbol names, which is useless for us because we strip debug info for our release builds.
workingjubilee commentedon Sep 13, 2024
Yeah, we really ought to come up with a better way to support decent backtraces than stuffing a DWARF parser in every single binary.
workingjubilee commentedon Sep 13, 2024
That or at least make the DWARF parser a lot smaller. Really, I thought they were supposed to be shorter than both Men and Elves, but I've seen an ELF or two in my time that were massively outweighed by their DWARF...
15 remaining items