On 15/06/2013 9:49 AM, Patrick Walton wrote:
On 6/15/13 1:26 AM, Graydon Hoare wrote:
I saw some more speculation on how to make rustc not-so-terriby-slow to
compile today, including dramatic structural changes like splitting it
into sub-crates. Please don't do this; it's papering over much more
readily solvable problems. A 80kloc library does not need to be
generating 16mb of object code.

I don't understand why you object to splitting librustc into subcrates.

Because it was being proposed as a solution to speed, but:

  - Bors cycle time won't improve.

  - "Make check" / testsuite cycle time won't improve.

  - Since binary compatibility between crates is broken now anyways,
    anything aside from the topmost-crate in a dependency graph perturbs
    link-compatibility with everything else. Just changing 1 line.

  - Even if that was fixed, dependencies are dependencies; you touch
    the typechecker's type / interface surface, it's going to need to
    rebuild the dependent crates. Many changes do this.

  - Even if not, it's a self-hosting compiler and many changes only
    emerge in stage1-target / stage2. It won't help those steps.

This is something that should be done regardless, for separate
compilation and tooling reasons. Note that clang has separate CodeGen
and Sema libraries for this reason.

I agree with that. I don't object to it being in multiple pieces in principle. But as speed work, it'll soak up some (very scarce) optimization time spent on what I see as a not-terribly-helpful diversion.

I would understand if people were suggesting that we just split rustc
into subcrates and stop working on compilation speed. But nobody is, or
has ever, suggested that.

We have limited time to allocate between activities, that's all. Every time I've proposed we spend time on optimizing, I've been told feature work is more important. I accept those priority judgments but with the caveat that we not lose sight of the technical debt that needs repaying. These problems have been around for months, some years.

-Graydon

_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to