standard library results in enormous binaries

[thestinger]

The initial binary size in C is ~3-8K, while Rust binaries using the standard library start at 2MiB. This problem doesn't stop with the initial code size and continues to grow at a rate much faster than C or C++ applications performing the same work. This is not a Rust compiler issue as it doesn't occur when not using the standard library, even when using an API at the same level of abstraction.

Rust is linking dynamically against the system libraries so there's really no excuse for them being this large. The code size needs to be in the same ballpark as C++ (at most 2x or 3x as large...).

[alexcrichton]

Changing the title to what the real issue is at hand.

[alexcrichton]

The vast majority of this size is because these items are included in all rust binaries by default right now:

• libgreen
• librustuv
• libstd
• libuv
• rustrt/morestack/small native tidbits

There are a few reasons for the inclusion of these bits:

• The rust compilation model produces one object file by default. This means that the entire contents of each rust library can be found in one object file. Linkers discard object files that are never used during linking, but because you'll always use at least one symbol from your dependent libraries it means that the linker pulls in the whole library every time. LTO solves this problem.
• Even with LTO, binaries are quite large. Even when using just libnative instead of libgreen, librustuv, and libuv binaries are still quite large with LTO. The reason for this is because of the I/O design. I/O objects are all created through a trait object, which means that it has a vtable of all its functions. This means that all I/O constructors in libnative/libgreen are forced to be included despite having LTO enabled. There are various ways to get around this, but none I have thought of have been very elegant.

As usual, dynamic linking binaries that are not very large in size. We have not turned this on by default due to the instability of the ABI of a library throughout recompilations.

[thestinger]

This issue isn't just about the initial code size when using static linking. The design of the generic functions/types in the standard library causes very bloated code. It will get a bit better when the old vector implementation is gone, but there's a serious lack of code (as in runtime machine code) reuse in most of the modules. I think we can do a lot better with a little thought put into hoisting out some code. The mergefunc pass isn't good enough because LLVM will never hoist out the common parts of generic functions.

[thestinger]

Also, fn main() {} isn't using I/O so even with static linking I don't see why the initial code size would be above 4K. I don't think the initial size can be explained by trait objects, as int main(void) {} in C consists of a single function and the Rust equivalent should too.

[pcwalton]

Can you be more specific? It'll be hard to close this issue without specifics.

[thestinger]

Replaced with #13097.