It'd be nice if the default was external symbols rather than none at all
Making Rust binaries smaller by default
31–40 of 199 posts
Re: Making Rust binaries smaller by default
#32So what's in the remaining huge 415KB hello world program? Can we get rid of 90% of it a couple more times?
Buffered I/O and synchronization primitives to avoid corrupting the buffer. The underlying vector implementation and memory allocator. Panic support and backtrace printer, which includes a Rust-specific name demangler and a not-so-small DWARF parser in Linux. Path support because backtraces would include source file paths. Zlib-compatible decompressor because ELF allows compressed sections (!). Then you have several formatters that are often pretty large (e.g. f32 and f64 would add at least 30 KB of binary, and some depend on Unicode grapheme clusters). They are all essential for edge cases that can happen even for such a simple program.
Re: Making Rust binaries smaller by default
#33[flagged]
I have implemented the fix and got it approved in the span of about 3 weeks (and that was over the Christmas!). Doesn't seem that bad to me, given that it's a change that will affect pretty much any Rust user by default.
Even if just focused on time alone, that's 3 weeks and all the years when you kept rediscovering it
Then there is the fact that it required establishing the whole working group
All for a simple fix that positively affects pretty much any Rust user
Re: Making Rust binaries smaller by default
#34Re: Making Rust binaries smaller by default
#35So what's in the remaining huge 415KB hello world program? Can we get rid of 90% of it a couple more times?
Buffered I/O and synchronization primitives to avoid corrupting the buffer. The underlying vector implementation and memory allocator. Panic support and backtrace printer, which includes a Rust-specific name demangler and a not-so-small DWARF parser in Linux. Path support because backtraces would include source file paths. Zlib-compatible decompressor because ELF allows compressed sections (!). Then you have several…
Why does it need to parse elf ?
Re: Making Rust binaries smaller by default
#36It'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…
A vast majority of that 415 KB is due to the backtrace support, which is amazingly complicated. (See my other comment for specifics.) It will depend on some more machinaries from std, and a "simple" hello world can always panic if stdout is closed or so, therefore that part of std cannot be easily removed unless you are fine with useless backtraces.
Also, Rust has no direct platform support unlike C. So everything has to be statically linked to be portable. A statically linked glibc is indeed much larger than that (~800 KB in my machine). Conversely, you can sacrifice portability and link to `libstd*.so` dynamically to get a very small binary (~17 KB in my machine, both for C and Rust).
Re: Making Rust binaries smaller by default
#37Earlier quoted context omitted.
Buffered I/O and synchronization primitives to avoid corrupting the buffer. The underlying vector implementation and memory allocator. Panic support and backtrace printer, which includes a Rust-specific name demangler and a not-so-small DWARF parser in Linux. Path support because backtraces would include source file paths. Zlib-compatible decompressor because ELF allows compressed sections (!). Then you have several…
Why does it need to parse elf ?
The stack frame is a list of return addresses which have to be translated to a file name and line number. Such debug information is within a specific ELF section in the predefined format. In this simple case you may be able to hard-code the offset to the section (and guarantee that it was never compressed), but any additional C or Rust library will break this assumption, so a general parser has to be included.
Re: Making Rust binaries smaller by default
#38It'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…
> 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.
Re: Making Rust binaries smaller by default
#39I 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 profiling or debugging in any meaningful way...
Re: Making Rust binaries smaller by default
#40[flagged]
I have implemented the fix and got it approved in the span of about 3 weeks (and that was over the Christmas!). Doesn't seem that bad to me, given that it's a change that will affect pretty much any Rust user by default.
I was curious about how an implementation for this would work and browsed the PR. Cool stuff, thanks for putting the effort in!
I noticed a very tiny typo which doesn't affect behaviour I think. https://github.com/rust-lang/cargo/pull/13257/files#r1464506...