4 ms·
Both executables have grown on my machine since 2016. On Linux, no optimization or stripping * C Hello World - 19K * Rust Hello World - 1.6M (!) The C gain i
by edflsafoiewq 7y ago
Both executables have grown on my machine since 2016. On Linux, no optimization or stripping
* C Hello World - 19K
* Rust Hello World - 1.6M (!)
The C gain is attributable to a change to ld: it puts read-only data and executable data in separate segments by default as a security hardening measure since ld 2.30. I don't see why this shouldn't produce three segments (R, RE, RW), but here I get four (R, RE, R, RW). (Anyone know why four?) If I pass -znoseparate-code to disable this the C goes back to the 8K shown in the article. (No effect on the Rust).
The Rust gain appears to be mostly in debug info. Stripped I get 187K, which is similar to 121K the article gives after stripping and removing jemalloc (which isn't in by default anymore).
Does anyone know why Rust has grown so much from 2016 to 2019?
- dathinab 7y agoDid you compile with the --release flag? Without it will build a debug build and put all the debug info in there (which mainly due to println is a lot).
- edflsafoiewq 7y agoIt doesn't make any difference for something as small as hello world (you can try it). A release build might not have debug info in the sense that -C debuginfo=0, but it still has plenty of stuff that can be stripped. You also get the same size if you bypass the println machinery with io::stdout().write_all(b"Hello, world!").
- Grollicus 7y ago$ cargo --version && cargo init hello && cd hello && cat ./src/main.rs && cargo build --release && du -h ./target/release/hello cargo 1.34.0 (6789d8a0a 2019-04-01) Created binary (application) package fn main() { println!("Hello, world!"); } Compiling hello v0.1.0 (/tmp/foo/hello) Finished release [optimized] target(s) in 0.31s 1,6M ./target/release/hello Edit: $ strip target/release/hello && du -h ./target/release/hello 192K ./target/release/hello
- the8472 7y ago164K after fat lto, Os, panic=abort and stripping on nightly 2019-05-12
- aasasd 7y agoNote that, while it doesn't matter much in this case, with `du` you'll get ~±4Kb out of nowhere because it measures by fs blocks. You need `--apparent-size` for the file size―which doesn't exist in the BSD version (= MacOS version).
- taneq 7y agoMy C++ 'hello world' program on Borland C++ Builder back on Windows 3.1 was about a megabyte, far larger than an equivalent program today. Executable size is a characteristic of the compiler, not the language. Rust is still a very young language and I'd imagine it's currently focusing on other things and will get round to optimizing output size.
- deg4uss3r 7y agoHuh, 271K on MacOS using debug (268K using release).. Edit: 1.34.2
- edflsafoiewq 7y agoThe larger size on Linux is because the binary itself contains the debug symbols. On Mac, they're in a separate .dSYM file from what I understand. See https://github.com/rust-lang/rust/issues/46034 https://github.com/rust-lang/rust/issues/46034. According to that thread, the size jump of the unstripped binary is probably from libstd being compiled with -C debuginfo=1 now.
- deg4uss3r 7y agoAh thanks, that makes sense!
- pornel 7y agoRust on Linux has a bug that it puts libstd's debug info into the executable, even in release mode. You need to run `strip` on the executable :(
- edflsafoiewq 7y agoBut even the stripped executable has grown by ~50%.