Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Rust binaries smaller by default

kobzol.github.io

Post reply on HN
Print view View original

41–50 of 199 posts

Re: Making Rust binaries smaller by default

#41

Post by emi2k01 »

milianw wrote: post #39

I applaud this initiative. yet I wonder - the ideal situation would be to not throw away the debug info (ever), but rather it should be put into an external file. even Linux supports this for many years and nowadays we even have direct support with dwarf5/dwo. is trust taken any action towards that direction? after all: without debug info (which you do not want to ship to customers necessarily), you cannot do profili…

Splitting the debug info from the executable is supported on the 3-big-OSes but only enabled by default on Windows (and maybe macOS?)

Re: Making Rust binaries smaller by default

#42

Post by [deleted] »

Humphrey wrote: post #2

> I can imagine a situation where a seasoned C or C++ programmer wants to try Rust, compiles a small program in release mode, notices the resulting binary size, and then immediately gives up on the language and goes to make fun of it on the forums. While I'm not a seasoned C or C++ programmer I have definitely done this to a few new languages when playing around with them. My thought was "If helloworld.rust is this l…

[deleted]

Re: Making Rust binaries smaller by default

#43

Post by lifthrasiir »

zozbot234 wrote: post #22
anonymoushn wrote: post #17

Earlier quoted context omitted.

I would hope that it could statically link libc and exclude the unreachable portions.

Rust can't do this very well because it doesn't build std as part of the project, that's still an unstable option. It's linking object code.

Link-time optimization should have been beneficial for this case... unless you absolutely needed quite a bit of `std` to print backtraces.

Re: Making Rust binaries smaller by default

#44

Post by goku12 »

emi2k01 wrote: post #41
milianw wrote: post #39

I applaud this initiative. yet I wonder - the ideal situation would be to not throw away the debug info (ever), but rather it should be put into an external file. even Linux supports this for many years and nowadays we even have direct support with dwarf5/dwo. is trust taken any action towards that direction? after all: without debug info (which you do not want to ship to customers necessarily), you cannot do profili…

Splitting the debug info from the executable is supported on the 3-big-OSes but only enabled by default on Windows (and maybe macOS?)

Many Linux distributions have debuginfod servers that supply split debugging symbols on demand. So one could argue that it's implemented by default on Linux too.

Re: Making Rust binaries smaller by default

#45

Post by nindalf »

lionkor wrote: post #4

Initial binary size, like of a hello world, is a great indicator of how much abstraction the language has that youre also paying for. For example, java has to set up a constants pool, parse it from the classfile, run init and cinit, resolve references, allocatea a frame, and so on, just to get to the entrypoint. Compared to C without stdlib which needs to basically just run a few bytes to syscall write(). There are o…

It’s funny, because your claim that it’s a great indicator is contradicted by the article we’re discussing. Rust was widely considered to be “only pay for what you use” despite having 4MB hello world programs. And now that it’s 400KB that continues to be true. So in this case, 4MB wasn’t a good indicator was it?

Re: Making Rust binaries smaller by default

#46

Post by EasyMark »

Humphrey wrote: post #2

> I can imagine a situation where a seasoned C or C++ programmer wants to try Rust, compiles a small program in release mode, notices the resulting binary size, and then immediately gives up on the language and goes to make fun of it on the forums. While I'm not a seasoned C or C++ programmer I have definitely done this to a few new languages when playing around with them. My thought was "If helloworld.rust is this l…

They're really gonna panic when they deploy their first qt app then.

Re: Making Rust binaries smaller by default

#47

Post by flohofwoe »

zozbot234 wrote: post #38
flohofwoe wrote: post #30

Earlier quoted context omitted.

It's not a great sign that this bug existed for 7 years, people noticed, asked about it, wrote tickets, everybody agreed that it should be fixed but then nobody took the time to actually do it (and the eventual fix is a rather crude hack by just stripping the output binary instead of preventing that debug symbols slip into a release binary in the first place). Looks more like a systemic issue in the Rust development…

> but then nobody took the time to actually do it That happens all the time, it's called prioritizing. If you don't let people prioritize, they will burn out and leave the project. That's not what you want.

If people only pick "interesting" problems to work on and ignore fundamental (but boring) issues like this, then those issues will just pile up and frustration and burnout will grow even more in the long run. At some point you'll have to stop feature development for a while and put all hands on cleaning up the accumulated cruft.

Re: Making Rust binaries smaller by default

#48

Post by riquito »

anonymoushn wrote: post #21

So what's in the remaining huge 415KB hello world program? Can we get rid of 90% of it a couple more times?

32Kb with the following configuration, on a linux target. It's not the default, you're using nightly, it's more complex to build and there are tradeoffs. You can even go less than that if that's your thing

  [profile.release]
  strip = true
  opt-level = "z"
  lto = true
  codegen-units = 1
  panic = "abort"
cargo +nightly build -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort --target x86_64-unknown-linux-gnu --release

As mentioned in another thread, I've simply followed https://github.com/johnthagen/min-sized-rust

Re: Making Rust binaries smaller by default

#49

Post by alpaca128 »

flohofwoe wrote: post #30
LAC-Tech wrote: post #25

It's great to see rust maturing. That people care about binary size and work to improve it is a good sign.

It's not a great sign that this bug existed for 7 years, people noticed, asked about it, wrote tickets, everybody agreed that it should be fixed but then nobody took the time to actually do it (and the eventual fix is a rather crude hack by just stripping the output binary instead of preventing that debug symbols slip into a release binary in the first place). Looks more like a systemic issue in the Rust development…

> nobody took the time to actually do it

Because in the end almost nobody actually cares about it enough to create a fix.

Small binaries are great, but people care mainly about how fast it compiles and how fast it runs, and in the few cases where the binary size is important it was already possible to shrink it significantly (more than with this new change). In my entire life I have never heard a user complain about the size of the binary, what people really care about is efficiency/speed at runtime. That's why people regularly mention VS Code using Electron, but not that its installation package alone has >500MB.

Re: Making Rust binaries smaller by default

#50

Post by lifthrasiir »

flohofwoe wrote: post #47
zozbot234 wrote: post #38

Earlier quoted context omitted.

> but then nobody took the time to actually do it That happens all the time, it's called prioritizing. If you don't let people prioritize, they will burn out and leave the project. That's not what you want.

If people only pick "interesting" problems to work on and ignore fundamental (but boring) issues like this, then those issues will just pile up and frustration and burnout will grow even more in the long run. At some point you'll have to stop feature development for a while and put all hands on cleaning up the accumulated cruft.

The issue was initially filed in 2017, but was partially solved by the introduction of `strip = true` in 2020 (nightly) or 2022 (stable). The OP wrote a concrete and comperhensive proposal to fully solve the issue in late 2023. Unlike your claim, people did periodically revisit this issue and even largely solve it.
Post reply on HN