Thanks Felix. I added this to https://github.com/mozilla/rust/issues/4047
On 11/29/2013 05:46 AM, Felix S. Klock II wrote:
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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
--
irc: pnkfelix on irc.mozilla.org
email: {fklock,pnkfelix}@mozilla.com
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
