-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stdlib code size increase in nightly-2024-09-01 for aarch64-linux-android #130320
Comments
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. |
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 |
@jrose-signal Does this affect the size of any completed binaries you use? |
Yes, the .so being measured here is the aarch64 slice of libsignal, as shipped in our Android app. |
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. |
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. |
Yeah, we really ought to come up with a better way to support decent backtraces than stuffing a DWARF parser in every single binary. |
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... |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
Oh, whoops. TIL. (Even for Tier 2 targets like Android? Nice.) |
Yeah, as long as you can run the test by cross-compiling. |
Could this be related to rust-lang/backtrace-rs#656? |
For a default
(and current nightly is still similar to the latter)
So yes, The |
Here's a comparison of
There's significant growth in |
Below are numbers for the same library on
|
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
ANDROID_NDK_HOME=path/to/ndk/27.0.12077973 java/build_jni.sh android-arm64
RUSTUP_TOOLCHAIN=nightly-2024-09-01
.bloaty
to measure VM size onlyIt'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
The text was updated successfully, but these errors were encountered: