Comment by palata
Comment by palata 4 days ago
> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...].
They don't say what they did about it, do they? Did they just accept it?
Comment by palata 4 days ago
> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...].
They don't say what they did about it, do they? Did they just accept it?
Probably yes. It's ~300KB per binary, and it's a one-time cost.
It can be avoided entirely by disabling the standard library, but that's inconvenient, and usually done only when writing for embedded devices.
Usually the problem isn't the size directly, but duplication of Rust dependencies in mixed C++/Rust codebases.
If you end up with a sandwich of build systems (when you have library dependencies like C++ => Rust => C++ => Rust), each Rust/Cargo build bundles its copy of libstd and crates. Then you need to either ensure that the linker can clean that up, or use something like Bazel instead of Cargo to make it see both Rust and C++ deps as part of a single dependency tree.
Posted elsewhere but The default hello world stripped with one codegen unit and panic=abort was 342kB both nightly and stable. Adding lto dropped it 42kB in stable and 40kB in nightly. Adding build-std and only building core did not reduce it any further in size.
I agree, but if you use more of the std library it will contribute more to the final image. I can write a 100 line rust file that ends up being 1MiB (even after lto) because I maximize as much code from the standard library as possible. This is not a knock on rust, but your statements can be a misleading as well. In practice most folks ignore the majority of the standard library so only a few hundred kib of std library end up in their binary.
Can it do lto on stdlib even without the nightly build-std flag?
I mean you get one upfront cost for things like allocators, common string manipulation and std::fmt, std::{fs, io, path} helper functions, and gathering of pretty backtraces for panics (which is a surprisingly fiddly task, including ELF+DWARF parsers and gzip to decompress the debug info).
A println!("hello world") happens to pull in almost all of it (it panics if stdout is closed).
Later code growth is just obviously proportional to what you're doing, and you're not getting a whole new copy of std::fmt every time you call print.
We invested a lot into build system optimizations to bring this number down over time, although we did accept on the order of 200 KiB size overhead initially for the stdlib. We initially launched using a Gradle + CMake + Cargo with static linking of the stdlib and some basic linker optimizations. Transitioning WhatsApp Android to Buck2 has helped tremendously to bring the size down, for instance by improving LTO and getting the latest clang toolchain optimizations. Buck2 also hugely improved build times.
Who knows what they did, but there are things which can be done: https://github.com/johnthagen/min-sized-rust
I suspect they just use no_std whenever its applicable
https://github.com/facebook/buck2/commit/4a1ccdd36e0de0b69ee...
https://github.com/facebook/buck2/commit/bee72b29bc9b67b59ba...
Turn out if you have strong control over the compiler and linker instrumentations, there are a lot of ways to optimize binary size