Hacker News Reader

Comment by fmntf | Hacker News Reader

If that's possible, why should not binaries be small (without too many downsides, eg execution speed) by default?

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

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

Interestingly enough, I would say that dynamic linking makes binaries smaller, that code no longer lives in the binary, but another place instead.

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

Yes, 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)

Sure. But there's a lot of overhead that comes with it, too.

Just like C compilers, it is a matter of use case, and compiling for size has tradeoffs regarding execution speed.

Reply on news.ycombinator.com