4 ms·
If that's possible, why should not binaries be small (without too many downsides, eg execution speed) by default?
by fmntf 6y ago
If that's possible, why should not binaries be small (without too many downsides, eg execution speed) by default?
- pjmlp 6y agoJust like C compilers, it is a matter of use case, and compiling for size has tradeoffs regarding execution speed.
- steveklabnik 6y agoBecause everything is a tradeoff. Getting the binary to be smaller means taking more compile time, because compilers have to do work to reduce the size. It is much faster to produce larger binaries. Additionally, most compilers produce something that's useful for development and debugging by default, and that means including extra stuff for that purpose.
- mlyle 6y agoA big part of why binaries are "big" is dynamic linking and external symbols. That Rust hello world is just hand-crafted to never be linkable to anything else at runtime and invoke a system call with a buffer. This isn't really how we'd like to do most things.
- steveklabnik 6y agoInterestingly enough, I would say that dynamic linking makes binaries smaller, that code no longer lives in the binary, but another place instead.
- djeiasbsbo 6y agoI'm pretty sure that for the classic "Hello World" example that's not the case, because we can simply use the linux write system call. For example, an assembly program that just calls write and then exits is much smaller than even an unlinked version of it that uses printf, because the ELF binary doesn't need to contain information for the linker.
- steveklabnik 6y agoYes, on the very very very low end, this is the case, but generally, in more real programs, it's not. (The program I linked is an example of exactly what you're talking about)
- mlyle 6y agoSure. But there's a lot of overhead that comes with it, too.