rust package size has gone from 120MiB in 0.9 to 330MiB with master

[thestinger]

Both are providing support for static linking and link-time optimization. A 300% increase in size with no increase in scope of the libraries is quite bad. The standard library itself went from 39M to 42M but this can be explained by the added features and some cases of temporarily duplicated code like Vec<T> and ~[T]. I have not yet investigated the exact cause of the enormous increase in size.

[alexcrichton]

Some obvious wins that we can get (this is just the size of the rustlib/$target directory)

• compress foo.bc in each rlib, 274MB => 257MB (-17MB)
• remove foo.bc from each rlib, 274MB => 234MB (-40MB)
• compressing metadata, compressing foo.bc 274MB => 146M (-128MB)

rlibs are generally twice the size of their corresponding dylibs, this is because they include object code (foo.o) as well as bytecode (foo.bc). I think that the big takeaway is that rlibs are way too big for their own good right now. We get some speed from reading uncompressed metadata, but these numbers are so absurd it may be best to just continue compressing metadata. I don't see why we wouldn't compress bytecode files because they're only used during LTO anyway.

[thestinger]

@alexcrichton: We already had the rlib files in 0.9 with the LTO object code though. I'm not sure why the total size has gone up so much... it seems there's some duplication we could be killing off.

[mneumann]

I wonder if we really need both rlib and dylib in all situations? To me it sounds that rlib's include everything that a dylib includes, right? So in case a rlib exists, do we really need a dylib of the same name?

[alexcrichton]

Aha, we also appear to be distributing rlib versions of lib{rustc,syntax,rustdoc,fourcc} which we were not previously doing.

[alexcrichton]

it sounds that rlib's include everything that a dylib includes

Sadly no, rlibs include uncompressed metadata (much faster to read) and bytecode (used in LTO).

So in case a rlib exists, do we really need a dylib of the same name

If you're creating a dynamically linked executable or library, you'd have to convert rlibs to dylibs each time you link against them, and at some point you're going to need a dylib living somewhere on the system, so sadly I don't think that this will work.

Inversely, I don't know of a way to link against a dylib statically, so we need the rlibs around for static linking.

[thestinger]

This regression is mostly fixed, although it's still way too big.