First off, the topic of rustc slowness and long bootstrap times has
indeed been discussed many times. If you have not yet tried skimming
the archives, I recommend doing so, e.g. via
http://lmgtfy.com/?q=+site%3Amail.mozilla.org+rust+crate+compilation+speed
(I provide a (surely incomplete) list of previous-post links below.)
----
Now, a request: when discussing this topic, please try to avoid conflating:
1. librustc+libstd bootstrap time,
from the somewhat separate issues of
2. models for incremental compilation, and
3. compilation times when running rustc on projects other than rustc
itself.
In particular, incremental compilation alone is not going to solve (1).
(At least, not as long as one is using the default make rule that
rebuilds all of librustc+libstd atop the newly built rustc, and rustc
itself draws upon a (large) libstd. Under the latter two constraints,
you *have* to redo the build for all of librustc+libstd: the compiler
itself was changed. Incremental compilation does not solve this.)
I am concerned that we will waste time debating tasks/designs related to
(2) and then people will be disappointed when it does not provide the
gains that they were expecting for issues like (1).
----
In case its not clear from the comments above: the team is well aware
that rustc itself runs more slowly than it should; it is a common topic
of discussion.
The team is also well aware that the time to bootstrap librustc+libstd
is longer than many developers can cope with.
I am not sure I agree with the assertion that the approach of breaking a
project into multiple crates is not a solution. Yes, we may need better
tools here (though I don't know how much rustpkg could help with this
problem).
----
As promised, here are some relevant links to previous posts. In *all*
of the cases below, the *whole thread* is often worth review.
* A great overview from pcwalton
Thread subject: " Why does Rust compile slowly?"
https://mail.mozilla.org/pipermail/rust-dev/2012-October/002462.html
* In early 2013 there was discussion of easing crate decomposition:
Thread subject: " Plans for improving compiler performance"
https://mail.mozilla.org/pipermail/rust-dev/2013-January/002878.html
* strcat and graydon each had good points in this discussion:
Thread subject: "Please tell me about making rustc faster"
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004326.html
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004328.html
* The team internally discussed whether to break lubrustc into
multiple subcrates here:
Thread subject: " code generation and rustc speed"
https://mail.mozilla.org/pipermail/rust-dev/2013-June/004493.html
Cheers,
-Felix
On 29/11/2013 12:22, Guillaume HERVIER wrote:
+1 for this issue. I think that compilation time is really important
if we want Rust to be used as production language.
For example, I think that if we can reduce significantly the Rust
compiler's compilation time, it could allow more developers to
contribute to the Rust language (as they won't have to wait 30min for
each small modifications in the compiler).
Personally, it's the only thing which blocks me when I want to
contribute to Rust, because I like to often compile code when I do
small modifications to test each of these small modifications, partly
because I don't know the language very well.
On 11/29/2013 12:01 PM, Léo Testard wrote:
Hello,
I think everyone here will agree to say that compilation times in
Rust are problematic. Recently, there was an argument on IRC about
reducing compilation times by reducing the use of GC and failures.
Although I agree it's good to reduce Rustc's overhead, I think there
are more important problems. The total duration of a build matters
only because you have to recompile the whole crate on each
modification. In C++, the duration of the complete build of a project
matters less because when you compile incrementally, you only have to
rebuild a couple of files - those you modified. I know the "1 crate =
1 compilation unit" is the model chosen by Rust, but this is a major
issue for production. Nobody will ever use Rust in production if they
have to recompile thousands of lines of code on each modification.
On some of my personal projects, I "solved" this problem by splitting
the codebase into several crates, that I compile statically, and then
link together using extern mod. This is not really a solution,
because this implies that there is no cyclic dependency between each
of the small crates, or I end up with issues trying to compile it,
because using extern mod requires that the library corresponding to
that mod exists before compiling the crate that depends on it.
But strictly speaking, a compiled crate is nothing more than a module
hierarchy, and so is a single Rust source file, so we should be able
to compile a single file to some sort of .o and then link all
together to form a crate. References to modules outside of this file
just require the first passes of the build, not the code generation,
so it should be ok regarding to cyclic dependencies, and if not, we
could still introduce some kind of auto-generated interface file,
like Caml does. I know it's quite a big work, and that the current
system is quite good, but having this is very important if we want
Rust to be used in production.
Sorry if this topic has already been posted several times, but I feel
this is important, and the related issues seem to date (#2369). I
think it's a real mistake to report this to post-1.0.
Leo
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix on irc.mozilla.org
email: {fklock, pnkfelix}@mozilla.com
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
