Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The `rustc` crate is too big, which hurts compile times for the compiler itself #65031

Open
nnethercote opened this issue Oct 2, 2019 · 6 comments

Comments

@nnethercote
Copy link
Contributor

commented Oct 2, 2019

The results from @ehuss's new cargo -Ztimings feature really drive home how the size of the rustc crate hurts compile times for the compiler. Here's a picture:
a
Things to note.

  • The rustc crate takes about twice as long to compile as the rustc_mir crate, which is the second-biggest crate.
  • Sixteen dependent crates start and finish their entire compilation while the rustc crate's codegen is happening. (Thank goodness for pipelining, it really makes a difference in this case.)
  • Almost 1/3 of the total build time occurs while building the rustc crate without anything else happening in parallel (from 42-67s, and from 141-174s).

Also, even doing check builds on rustc code is painful. On my fast 28-core Linux box it takes 10-15 seconds even for the first compile error to come up. This is much longer than other crates. Refactorings within the rustc crate that require many edit/compile cycles are painful.

I've been told that rustc is quite tangled and splitting it up could be difficult. That may well be true. The good news is that the picture shows we don't need to split it into 10 equal-sized pieces to get benefits. Even splitting off small chunks into separate crates will have an outsized effect on compilation times.

@petrochenkov

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2019

librustc still has a lot of code that's "just implementation code" and not something infrastructural like types or traits used in the rest of the compiler.

If we look e.g. at rustc/middle: resolve_lifetime.rs - just a pass, can be moved to rustc_resolve, stability.rs - just a pass, can be moved to rustc_passes or something.

@crlf0710

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2019

On my windows box, crate rustc takes about 2000 seconds to build... Grateful to anything that makes the compilation process faster.

@RalfJung

This comment has been minimized.

Copy link
Member

commented Oct 12, 2019

One thing that would be nice to move back from librustc to librustc_mir is all the memory access logic of the Miri interpreter, which these days lives in librustc::mir::interpret::allocation. But @oli-obk moved it there because it is used by things that do not depend on librustc_mir, so I am not sure what it would take to make that happen.

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

commented Oct 12, 2019

Can those things not depend on librustc_mir, e.g., being dependencies of librustc_mir? Can @oli-obk comment on that perhaps?

@oli-obk

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2019

Most of the datastructures need to live there, because the incremental serializer lives there (though we could probably move both out) and because some of the interners intern types like Allocation. I'm not sure how much of the code is needed there, but we can't add inherent impls in downstream crates, so if we want inherent methods, we need to implement them there.

I've tried a few times to split things out of librustc, it's just so entangled with everything that I failed.

@RalfJung

This comment has been minimized.

Copy link
Member

commented Oct 18, 2019

but we can't add inherent impls in downstream crates, so if we want inherent methods, we need to implement them there.

If it's just that we could use extension traits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.