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

171–180 of 199 posts

Re: Making Rust binaries smaller by default

#171

Post by pdimitar »

Novosell wrote: post #59
cybrox wrote: post #29

Earlier quoted context omitted.

It's not ideally written but it's safe to assume if someone compiles a quick test program for that purpose and it ends up being 4MB, they might just move on to other options instead of starting to think about how they can manually reduce the binary size. When evaluating languages, you rarely look foor good enough results to work around.

My machine has 32GB of RAM, why should I care about binary size? For embedded, sure. But most people don't write for embedded. If it was like 1GB, sure. But it aint.

Because your employer might want the deployed final binary work fast on a 1 vCPU container with 1GB of RAM.

Re: Making Rust binaries smaller by default

#172

Post by kramerger »

pdimitar wrote: post #153
lifthrasiir wrote: post #103

Earlier quoted context omitted.

But why? I mean, I'm also obsessed of the byte size from time to time and I do often optimize for the size when it's doable, but in practice anything below 1 MB seems small enough that you don't need to optimize further. There are so many low-hanging fruits when it comes to the Rust binary size...

Mostly because CPU caches matter a lot. Executing 7-8 different Rust binaries, in a loop, that are each north of 10MB+ is bound to be less performant than corresponding smaller programs. Never had the time or dedication to actually verify this but I've been bitten by programs and OS-es that trash the cache too much and I've seen humanly perceivable lags because of it. But maybe in this case I am overreacting.

I think most debug info is in its own section. On a real OS the pages are loaded lazily so no (significant) performance hit.

Still, I hate big Rust binaries as much as the next guy.

Re: Making Rust binaries smaller by default

#173

Post by lights0123 »

pdimitar wrote: post #168
lifthrasiir wrote: post #114

Earlier quoted context omitted.

You are looking at the aftermath. Also, you could have manually put `strip = "debuginfo"` to avoid the 4 MB binary even before that; the issue is about the default when no `strip` option was given.

Actually my issue is with including the stdlib in its entirety, sorry for not clarifying. Indeed we could always strip the binaries and I've done so on every Rust project I worked on.

You are aware that the stdlib is linked with --as-needed which tells the linker to not include unused code, right? The entire stdlib is not included in Rust binaries unless you use the entire stdlib. However, as this article shows, that does not apply to debug info.

Re: Making Rust binaries smaller by default

#174

Post by pdimitar »

lights0123 wrote: post #173
pdimitar wrote: post #168

Earlier quoted context omitted.

Actually my issue is with including the stdlib in its entirety, sorry for not clarifying. Indeed we could always strip the binaries and I've done so on every Rust project I worked on.

You are aware that the stdlib is linked with --as-needed which tells the linker to not include unused code, right? The entire stdlib is not included in Rust binaries unless you use the entire stdlib. However, as this article shows, that does not apply to debug info.

Actually I was not aware, thanks for clarifying!

Hrm, I read the comments of another user who contributes to Rust and it seems there is various formatting / panic / abort / symbol and location translation code that contributes to the size and currently there is not much that can be done about it.

Oh well.

Re: Making Rust binaries smaller by default

#175

Post by cybrox »

Novosell wrote: post #59
cybrox wrote: post #29

Earlier quoted context omitted.

It's not ideally written but it's safe to assume if someone compiles a quick test program for that purpose and it ends up being 4MB, they might just move on to other options instead of starting to think about how they can manually reduce the binary size. When evaluating languages, you rarely look foor good enough results to work around.

My machine has 32GB of RAM, why should I care about binary size? For embedded, sure. But most people don't write for embedded. If it was like 1GB, sure. But it aint.

The other replies cover "the why" adequately already but as a tangent:

Every company makes some effort to be green and eco friendly these days, yet we're perfectly happy wasting billions of hours of compute time every second because "who cares" and "we can"... Same mindset.

Re: Making Rust binaries smaller by default

#176

Post by zer00eyz »

lifthrasiir wrote: post #117
zer00eyz wrote: post #113

Earlier quoted context omitted.

Out in javascript land no one cares about file size or wire time any more (but should) -- Over in C, plenty of people work on things where file size matters. It is a big deal. System constraints (embedded) wire constraints (far away systems where internet is slow and ephemeral), legacy systems where everything is going to be slow even moving that fat file around and you have to be present to update (ATM, ticket, vend…

I do have a lower threshold for JS apps, which is about 200 KB. This difference accounts for the fact that websites can be streamed while executables can't. I'm not saying that we shouldn't optimize for the size---rather I'm saying the size optimization is not worthwhile under some threshold.

I dont have a hard limit for JS...

What I have is a wall for functionality.

Loading 700kb react blob (compressed mind you) so I can read a web page is a hard no. You want to give me a rich GUI to do data editing in a browser, bring it on, I'll take the down load.

I know that rust and tiny go swap code here and there, binary sizes getting smaller on rust might make me give it a poke for some of the more "cute" embedded/iot things I like to play with... (another place where small matters!)

Re: Making Rust binaries smaller by default

#177

Post by pornel »

weinzierl wrote: post #155
kobzol wrote: post #149

Earlier quoted context omitted.

You can't really use dead code elimination on debug symbols, because you don't know which symbols will you need. You would need to know where and how will your program crash or if the user will want to use a debugger on it.

I don't understand. If a function isn't in the binary I will never need its name, so it does never have to be in the debug information. Likewise for variables.

I think linkers don't go this far to rewrite the debug info. If libstd is used, libstd's debug info is used.

The second problem is dynamic dispatch. The overhead in "hello world" is from printing and panicking machinery (it handles closed stdout), and these features use vtables, so it's even harder to precisely analyze what's actually used and what isn't.

Re: Making Rust binaries smaller by default

#178

Post by pornel »

flohofwoe wrote: post #72
lifthrasiir wrote: post #68

Earlier quoted context omitted.

Comparing with the current Cargo default [1]: • `panic = "abort"` means that any panic terminates the program. This is not always desirable because you may want to catch and recover from panics, particularly in long-running servers. • `strip = true` means that anything depending on DWARF would no longer work. Backtraces won't work, but also unwinding will no longer work (so this is disastrous if you haven't set `pani…

All makes sense, but I don't agree with: > This is not always desirable because you may want to catch and recover from panics, particularly in long-running servers. IMHO a panic implies that execution cannot continue under any circumstances, and even any attempts for a graceful shutdown might be futile (if recovery is possible it shouldn't be a panic but done through regular error handling). For a server process the…

> For a server process the best reaction to a panic would mean abort and clean restart.

That's often infeasible, and creates a major DoS/reliability problem.

The server may be processing hundreds of different requests at the same time, and panic=abort will kill all of them. That creates a visible failure to other unrelated clients of the server, not just the offending request.

If you try to fix that and retry aborted requests, you'll retry the panic-inducing request and cause another failure (and it'll take several restarts to bisect out the offending request).

Plus a restart may be costly, require loading data, warming up caches, etc.

It's just way cheaper to catch a panic and return 500 to the offending request. Rust guarantees to panic before anything terrible memory-corrupting happens. Even if you don't trust it and would prefer to restart anyway, you have an option to gracefully hand over the traffic before the restart.

Re: Making Rust binaries smaller by default

#179

Post by WhyNotHugo »

nindalf wrote: post #108
pdimitar wrote: post #100

It's really a shame that Rust includes the stdlib piecemeal in binary form, debug symbols and all, in every final binary. I do love Rust but binary sizes have always annoyed me greatly and I always had this nagging feeling that part of all programmers don't take Rust seriously because of it. And I actually have witnessed, several times in the last 2-ish years, older-school programmers berating and ignoring Rust on th…

> so I guess I'll have to wait several more years A feature that's landed in Rust nightly will be part of the next beta release (at most 6 weeks away) and then the following full release (exactly 6 weeks away). For this feature in particular, rustbot added a tag of 1.77.0, which is releasing on 21st March 2024, less than 2 months away. It's possible you've confused this with more complex features that stay on nightly…

Some features remain in nightly for years.

A very relevant example is `build-std`, which builds the standard library (and does LTO) instead of copying a pre-built one. This feature has been on nightly for at least a couple of years.

Re: Making Rust binaries smaller by default

#180

Post by deschutes »

0x000xca0xfe wrote: post #134
lifthrasiir wrote: post #103

Earlier quoted context omitted.

But why? I mean, I'm also obsessed of the byte size from time to time and I do often optimize for the size when it's doable, but in practice anything below 1 MB seems small enough that you don't need to optimize further. There are so many low-hanging fruits when it comes to the Rust binary size...

I work in embedded software and we fight for every megabyte of NAND flash. Multiple smaller executables add up, too. Reducing the binary size is usually more important than performance (and often more important than memory safety, if we are totally honest...). Personally, I hate bloated software just as much as slow software. It's crazy what you can do with 64 kilobytes, let the demoscene blow your mind: https://www.…

You can't be everything to everyone. Packaging considerations for niche use cases rightfully take a back seat to debuggability and packaging considerations in modern web deployments and consumer devices.
Post reply on HN