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

191–199 of 199 posts

Re: Making Rust binaries smaller by default

#191

Post by JohnFen »

zer00eyz wrote: post #113
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...

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…

> Out in javascript land no one cares about file size or wire time any more

Which is one of the reasons why I tend to leave JS disabled in my browser. Too many web devs have no care or concern for these sorts of things, which often makes JS a real resource drain.

Re: Making Rust binaries smaller by default

#192

Post by aseipp »

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.

This isn't a fundamental issue, but it is very, very boring.

Re: Making Rust binaries smaller by default

#193

Post by EasyMark »

flohofwoe wrote: post #77
EasyMark wrote: post #46

Earlier quoted context omitted.

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

Statically linked Qt 4.x wasn't actually so bad. But that's not compatible with the LGPL license for closed-source apps, you had to get a commercial license. The problem with DLL based Qt apps is that you ship a ton of code that's never called.

I was just thinking about the size of the app if you include all the needed libraries for even a basic gui app :) . I guess it was a bit tangential of an comment.

Re: Making Rust binaries smaller by default

#194

Post by pjmlp »

lifthrasiir wrote: post #103
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…

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...

That won't fit into a ESP32, Arduino or embedded hardware with similar restrictions, leaving the space for C and C++, or the Basic, Pascal compiler vendors still enjoying that space like Mikroe.

Re: Making Rust binaries smaller by default

#195

Post by IshKebab »

vacuity wrote: post #183
IshKebab wrote: post #162

Earlier quoted context omitted.

You aren't. They're only caught in special cases, e.g. if a thread panics and you want to propagate that to other threads, to catch panics in unit tests, to avoid unwinding across FFI, etc. You shouldn't use them as a general exception mechanism. They aren't the same, even if under the hood they both use stack unwinding.

Naively, what is the difference between panics and exceptions? Is it the philosophy on when/how to use them?

Yes, and also exceptions can have arbitrary value associated with them. You aren't going to get far using panics as a general error handling mechanism because there's only one type of panic.

Re: Making Rust binaries smaller by default

#197

Post by raggi »

berkes wrote: post #61
raggi wrote: post #31

It'd be nice if the default was external symbols rather than none at all

I'd find that a bit counterintuitive. To me, --release is an alternative for --debug. Debug implies debug stuff is in there, therefore the alternative removes it. But I do find it useful now and then to have debug symbols in production, so that monitoring and telemetry gets some context. But to me, it's rather logical that I need to add this to the build. I would, however, love it when it's trivial to get these symbo…

GNU binutils and LLVM both have support for debuginfod server topologies now, it would be great to see Rust tools get on the train.

https://github.com/llvm/llvm-project/commit/36f01909a0e29c10...

And naturally we already have a port: https://crates.io/crates/debuginfod-rs

Re: Making Rust binaries smaller by default

#199

Post by ragnese »

edflsafoiewq wrote: post #187
ragnese wrote: post #182

Earlier quoted context omitted.

Debug symbols increase the binary size and don't really have anything to do with the abstraction level of the language. My understanding is that you also don't really "pay for" the debug symbols at runtime (until you generate a stack trace and need them). There could be some nuance that I'm missing there.

More abstraction generally means more functions which means more debug symbols. For example, iterating over an array in Rust involves iterators, slices, options. There are lots of function calls, which all contribute debug info. In C, iterating over an array is a for loop and pointer arithmetic, no function calls, so much less debug info.

But that's abstraction that you're actually using. The parent to my comment was implying that the debug symbols are an indication of abstraction that you're paying for whether you use it or not (in contradiction to the "zero cost abstraction" mantra/motto of C++ and Rust).

You're perfectly welcome to just use a raw for loop with numeric indexes in Rust , in which case you wouldn't have those extra function calls for iterators, etc. Likewise, if you implemented an iterator abstraction in C, you'd end up paying a similar cost. So, that's not what the grandparent comment was talking about.

Post reply on HN