-
Notifications
You must be signed in to change notification settings - Fork 13.4k
stdlib code size increase in nightly-2024-09-01 for aarch64-linux-android #130320
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: