Making Rust binaries smaller by default
kobzol.github.io
Making Rust binaries smaller by default
1–10 of 199 posts
Re: Making Rust binaries smaller by default
#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 large, it'll be huge once I've actually written more code".
Re: Making Rust binaries smaller by default
#3> 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…
Yup same. Also I hate the "just strip it" advice. I don't know who on earth strips random binaries and has them actually work fine afterward 100% of the time. Stripping after linking frequently breaks binaries I try it on.
Re: Making Rust binaries smaller by default
#4Initial 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 obviously massive advantages to Java for which these steps are needed, but you do pay for it.
Re: Making Rust binaries smaller by default
#5> 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…
That’s almost never the case, though. Imagine if a C binary statically linked in libc. Adding a page full of more C to its code would only grow it a tiny amount.
Re: Making Rust binaries smaller by default
#6> To reduce download bandwidth2, it does not come in two variants (with and without debug symbols), but only in the more general variant with debug symbols.
Why not instead only without?
Re: Making Rust binaries smaller by default
#7> 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…
Yup same. Also I hate the "just strip it" advice. I don't know who on earth strips random binaries and has them actually work fine afterward 100% of the time. Stripping after linking frequently breaks binaries I try it on.
All binaries on a classic Linux distro are stripped (you can use 'file' to quickly check some), so your issues might be worth reporting
Re: Making Rust binaries smaller by default
#8> To reduce download bandwidth2, it does not come in two variants (with and without debug symbols), but only in the more general variant with debug symbols. Why not instead only without?
If you have them, but don't want them, you can throw them out. If you don't have them, but want them (as does anyone who doesn't build in release mode when developing), you're out of luck.
Sure, you can rebuild the standard library, but it's a lot simpler to strip the output than set things up so the first time you want debug symbols, it has to rebuild std, cache it somewhere, not rebuild it again on the next build, but be sure to invalidate that cache the next time std gets updated.
And in general, not wanting debug symbols is the last step in development, before making your first release. Before then, you pretty much always want those debug symbols, except for when you're benchmarking binary size or something.
So if they were going to ship std without debug symbols, they'd probably just be better off not shipping a prebuilt std at all, as pretty much everyone would end up having to build it on first run of 'cargo build' anyway. (Which is maybe fine, actually?)
Re: Making Rust binaries smaller by default
#9My go to reference when I want to reduce rust binary size is the excellent https://github.com/johnthagen/min-sized-rust, a set of guidelines on how to reduce size with explanations of the consequences
Re: Making Rust binaries smaller by default
#10Initial 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…
I'm not trying to be rude, but what does your comment have to do with the actual article linked. I suspect you're commenting based solely on the title? If you read the article it mentions 90% reduction if you remove the debug symbols from the rust std lib that get bundled in the final hello world binary. A conversation about Java's size and abstraction is quite irrelevant to the article.