Change:
} } <ins> fn skip_host_target_lib(builder: &Builder<'_>, compiler: Compiler) -> bool { // The only true set of target libraries came from the build triple, so // let's reduce redundant work by only producing archives from that host. if compiler.host != builder.config.build { builder.info("tskipping, not a build host"); true } else { false } } /// Copy stamped files into an image's `target/lib` directory. fn copy_target_libs(builder: &Builder<'_>, target: &str, image: &Path, stamp: &Path) { let dst = image.join("lib/rustlib").join(target).join("lib"); t!(fs::create_dir_all(&dst)); for (path, host) in builder.read_stamp_file(stamp) { if !host || builder.config.build == target { builder.copy(&path, &dst.join(path.file_name().unwrap())); } } } </ins> #[derive(Debug, PartialOrd, Ord, Copy, Clone, Hash, PartialEq, Eq)] pub struct Std { pub compiler: Compiler,

Discussion:
Edit: The total Rust archive size has intensified recently. Is this a regression caused by ? cc (for the PR), (infra team)
modify labels: T-infra
Error: Label I-heavy can only be set by Rust team members Please let know if you're having trouble with this bot.
Yes, this is an expected regression by
See also
This contains justification of the change: This contains suggestions on decreasing the size: There are big in compilation speed, but mostly only startup improvements (relative speedup increasing the smaller the crate is), which makes sense if you read the comment by I've linked above: there is less work to do at load time of the binary.
My own suggestion: - reproduced below: We would have to either include MIR for everything and codegen at the end (potentially subopyimal) or just throw away the and somehow require the final crate to be linked in order to use anything from the component crates. For the latter, it could be as simple as a check like "at least one of the dependency crates must claim to contain each symbol referenced and be linkable".

I went to this page: and I discovered that the download is 203 MB. This was surprising to me, so I looked at other languages: Language Link ------------------------------- Go Perl Julia Python PHP D Nim https://nim- Ruby So Rust is 70% larger than Go. Or to put another way, Rust is larger than Julia, Python, PHP, D, Nim and Ruby combined. Can anything be done about this or is the large size unavoidable?
IIUC will reduce the size, potentially by a lot
Also the comparison might want to include Haskell, whose installer is 268 MB ().
These comparisons are probably missing various aspects, e.g. Haskell includes the full haskell platform with a list of packages as well as a runtime. Rust might include other things... We should compare with our past selves first and foremost.
where are you getting that 205 MB number from? When I try to download it tells me 252 MB so the problem is even worse than you say it is... Maybe linux vs windows? Some points for where the potential bloat could come from: licenses are stored multiple times for each package. Costs a few KB but I guess it can't be avoided. It would probably be useful to have a compression format that can do content based deduplication, but I guess there is none out there, is what we need to use. save analysis of all std crates is being stored. Using json, the save analysis format is extremely verbose. It contains repetitive stuff like references to the same source file over and over. It could probably be improved a lot by a) interning stuff like source file names and b) a binary format. As IIRC serde is used already for json output and input, adopting bincode would be a first easy step then followed by interning (interning can be done transparently from bincode). The save-analysis format is unstable and probably always will be, given that replacement is on its way with rust-analyzer. If there is ever a desire to stabilize, one can switch back to json. As for the point that we are using deflate compression, sure it helps but a native compression would help even more. rust's copy of LLVM is 76 MiB while julia's copy of LLVM is 48 MB (both uncompressed). Why is that the case?

Rust has LLVM 8.0 and julia 6.0 but that can't be the reason, has LLVM grown this much in size between two versions? there is a documentation directory that contains rustdoc/mdbook of various components. Each component has its very own copy of fonts (each almost half of a MB large). It's repeated multiple times. I'm sure much can be saved by using a shared copy of those fonts.
At least for Linux a lot of dependencies are linked statically (even libstdc++) to make it work on old Linux releases.
no need to wait for nightlies, the built artifacts are already being uploaded to public servers. This gives us the following size impact of : Numbers collected via commands like . So for rustc there is a nice sweet reduction but std has a massive size increase. why is this the case? Maybe some cache not being emptied?
also includes the compiler crates, and with there's duplication for these as the same code is included in the rlibs and 's dylib.
Hi, I have a question. What needs those rlib files in rust-std? Can I remove those rlib files from rust-std and have most crates build as normal? (I'm repackaging rust-nightly for Arch Linux.) It's 109MiB larger now and it'll take me four more minutes to download (what's worse, I can't watch online videos meanwhile)....
There are some generic bloat problems that Rust has like which increase binary size which probably play into Rust's large platform size, too.
Before a lot of symbols were placed into shared libs and duplication wasn't an issue. Many of those shared libs were replaced by static ones () which has benefits (better performance, simplification of Rust internals) and downsides (duplicated symbols, bigger size). Using archives instead of reduces download size of std by 30 MiB at the expense of extraction time. It can help with slow connections. Rust itself and the crates. Some of the libs aren't necessary for every use case but they are relatively small. Big libs which are the issue here cannot be removed. It doesn't mean nothing can be improved. Multiple dependencies are built multiple times, it's clearly visible with . In std from commit there are 2 with size 2 MiB each.

Most of the duplicates are much smaller but also harder to find because they don't have their own libs and can be found only inside other libs. EDIT: cc
thank you for the detailed response. However this part is concerning: that seems to be "cutting at the branches rather than cutting at the root". To compare Go 1.12.6 is 118 MB: Then Rust is 294 MB: thats nearly 2.5 times larger. I know every language is different but this seems too much.
It's not the solution by any means, I just wanted to make people aware of better compressed archives. seems too much. Yes, it's concerning for sake of the completeness there is another big compiler. Official is 325 MiB and for it's 262 MiB. It also means Rust is now bigged than GHC. That said nightly to nightly it's over 100 MiB download size regression and there should be an effort on reducing it but there is no immediate solution.
The two biggest are (85M) and (42M) -- are you sure those cannot be removed? I suppose nightly/unstable users may need those, but for stable ISTM we only need the artifacts from and (which includes the proc-macro shim).
We could potentially replace the s with just s, which would still allow to use those crates, we'd just need a way to force linking against (which contains the actual machine code from those crates). I've previously suggested this in
I'm sorry for being dense, but what is the reason for having two copies of the compiler? That is, each distribution contains the duplicates and (among many others).
are host libraries installed by the component, and are target libraries installed by the component. The latter may be used for cross compilation too. But yes, that duplication is unfortunate.
Can you explain more what purpose they serve for cross compilation? Targets which do not have host builds do not include a second copy of the compiler. Is it to support projects that link the compiler directly with ? I'm not sure I see how the target's is relevant for cross compiling.
Yes, you could cross compile something using rustc libs -- unstable, of course. But if goes through, we won't include this in anymore, probably just another optional component.