8 ms·

Rust's compiler is not fast. At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse.

by comex 9y ago

Rust's compiler is not fast. At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. This might change once rustc eventually gets proper incremental compilation (not the codegen-only thing that's currently in beta). Hopefully. Rust doesn't use header files, so in theory it should be possible to leapfrog C++ (at least until C++ gets modules standardized), but for now that's just theory. Right now, I don't do much serious work in Rust, almost solely because of compilation speed.

vvanders 9y ago
Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast. If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).
- steveklabnik 9y ago
  "rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.
  - bluejekyll 9y ago
    I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.
    - steveklabnik 9y ago
      > such as making cached precompiled libraries very easy to use. This is already true today; that is, this cost is only paid the first time you compile. It's still not fast enough for people. On my machine, a fresh build of rustc takes an hour, and small changes take 20 minutes, and even that makes it a giant pain. It's an ergonomic thing, IMO.
      - kibwen 9y ago
        > a fresh build of rustc takes an hour A bit influenced by the fact that rustc has to compile itself three times. :P
        steveklabnik 9y ago
        Sure, but as with all end-user stuff, I don't care what it has to do, just that it has to do it.
      - bluejekyll 9y ago
        I should have been more clear; I mean a solution for many devs to pull precompiled caches, and share those for the same version of libraries... this would also benefit CI, as all CI runs to be based off this.
    - pjmlp 9y ago
      Turbo Pascal 5.5 was compiling 34,000 lines/minute. https://edn.embarcadero.com/article/20803 https://edn.embarcadero.com/article/20803 And even today Delphi 10 is quite fast. Same applies to many other compiled languages with modules.
      - bluejekyll 9y ago
        I haven't worked with Pascal since 1999, I remember it being a much simpler language. And no where near as fun. Hilarity ensued when I didn't realize there was no garbage collector.
- WatchDog 9y ago
  Is it as fast as javac? Maybe on a line of code basis, but I imagine java is much simpler to to implement incremental compilation with. Since sources map pretty much 1 to 1 with classes, you mostly only need to recompile the class that changed.
  - swsieber 9y ago
    Unfortunately, it's not quite that easy since java inlines constants, plus you have to account for package protected, inherited methods, etc. that you don't have to implicitly import. But really, it's the constants that make incremental compilation slower...
- hyperpape 9y ago
  Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini. I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times it's worse.
  - vvanders 9y ago
    Mostly gut feeling :). To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.
    - fnord123 9y ago
      Maven takes a long long time to start up, but once it's ready, javac is pretty quick. Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air). I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath<T> and AsRef<T>, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)
      - wtetzner 9y ago
        > Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!) I always thought `cargo new` should have been called `cargo cult`.
    - pjmlp 9y ago
      So better try again with straight javac, Ant and Maven. Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse? http://androidbackstage.blogspot.de/2017/04/episode-64-gradleweiss.html http://androidbackstage.blogspot.de/2017/04/episode-64-gradl... https://www.youtube.com/watch?v=BKRK4SvMtRk https://www.youtube.com/watch?v=BKRK4SvMtRk The Android Gradle plugin being slow as molasses is a typical discussion theme at Google IO since it was introduced. Being partially written in Groovy also doesn't help.
- amorphid 9y ago
  When you compile Java from the command line, is the compiler smart enough to not recompile files that haven't changed? Or is that an IDE feature?
  - cytzol 9y ago
    javac itself doesn't do any incremental compilation and will happily compile over your .class each time (though you can tell it not to; see http://stackoverflow.com/q/8271282 http://stackoverflow.com/q/8271282) Build tools like Maven and Gradle, as well as IDEs' internal build tools, will be smart and compile only the changed files.
- pjmlp 9y ago
  I wish it would be on par with javac, but my experience compiling rustfmt, rustsym and racer tells me otherwise. Also a bit disappointed when compared with other languages that support modules, specially the ones whose toolchains support binary dependencies. Not everyone has a high end development workstation. I am however confident the experience will eventually improve.
brandur 9y ago
I was partly relying on the context offered by the article and my parent comment to imply that sure, Rust's compiler isn't the fastest in class, but the team has identified speed as a major outstanding problem and is working very actively to address it. Compilers are pretty hard. Languages like C and Go are able to short circuit the problem by having a simplistic type system, but the Rust team's main option here is hard work, and so far they seem to be more than willing to engage in it. > At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. Citation needed on that one. How can you even make that kind of comparison fairly?
- nickpsecurity 9y ago
  It's one of those things that's happened to so many people with so many C++ compilers on projects of any significant size that almost everyone says it. Happened to me with several where I moved from a Pascal-like language to find the compile time terribly slow even when I barely used the language. A lot of it is do to how the language's syntax, semantics, and esp templating are designed. Plenty of languages with even more flexibility compile faster than C++ due to better design.
  - brandur 9y ago
    Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.
    - nickpsecurity 9y ago
      Maybe I misread as I quickly moved through the thread. It does look ambiguous now. All I'll claim is horrible compile times on C++. I'm not sure where Rust is at now.
      - pjmlp 9y ago
kibwen 9y ago
> but usually it does far worse Cite a source? This isn't my experience at all, Rust is still way faster at compilation than C++ on average. The advantage that C++ currently has is ccache which helps avoid needless rebuilds (which pairs well with C++'s smaller compilation units relative to Rust); building this behavior into the compiler is part of what the incremental compilation initiative is addressing.
- lumpypua 9y ago
  https://michaelfairley.com/blog/i-made-a-game-in-rust/ https://michaelfairley.com/blog/i-made-a-game-in-rust/ > It consists of ~7700 lines of Rust ... > Compile times with Rust are Not Great. This is easily my single biggest gripe about Rust right now. The build for A Snake’s Tale takes 15+ seconds, which makes iterating rather tedious. The current incremental compiler work also doesn’t seem to make the build for A Snake’s Tale’s codebase any faster.
  - kibwen 9y ago
    That compile time is Not Great, but 15 seconds for 7700 lines of code isn't even close to "far worse than C++". :P If incremental compilation is showing no benefits whatsoever, then I'm guessing that time is largely attributable to linking (and I tend to doubt that 7700 lines of code is counting the basic third-party libraries that are required to create a crossplatform GUI app (but I'd love to be surprised!), which will contribute to linkage time... LLD please!).
  - stevedonovan 9y ago
    For a full rebuild, that's a reasonable C++ build time for a project of this size. But full rebuilds are not representative, if the project is composed of many independent compilation units. The compilation unit in Rust is the crate, which is an exe or a library, so currently the best strategy is lots of little crates, which is not so ergonomic (heh) with Cargo. Actually, the compiler isn't the bottleneck - most of the time is LLVM codegen. So 'cargo check' is fast - the miri MIR interpreter likewise.

by comex 9y ago

vvanders 9y ago

Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast. If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).

steveklabnik 9y ago
"rustc is too slow" is possibly our most commonly-heard feedback. I am glad that you don't find it onerous, but many still do.
- bluejekyll 9y ago
  I don't know... I really think it depends on the audience you're catering to. As someone who only ever deals with compiled languages, this has never seemed to be a problem. Now, viewing this as someone coming from Python, Ruby, Node, etc., I can see compilation as being annoying. Is it really the only reason that they are disliking the language or is that just a strawman? I wonder if too much attention is being paid to this. Now there are legitimate things we can focus on, such as making cached precompiled libraries very easy to use. This can especially be important in CI environments... This would also generally make most compilations fast.
  - steveklabnik 9y ago
    > such as making cached precompiled libraries very easy to use. This is already true today; that is, this cost is only paid the first time you compile. It's still not fast enough for people. On my machine, a fresh build of rustc takes an hour, and small changes take 20 minutes, and even that makes it a giant pain. It's an ergonomic thing, IMO.
    - kibwen 9y ago
      > a fresh build of rustc takes an hour A bit influenced by the fact that rustc has to compile itself three times. :P
      - steveklabnik 9y ago
        Sure, but as with all end-user stuff, I don't care what it has to do, just that it has to do it.
    - bluejekyll 9y ago
      I should have been more clear; I mean a solution for many devs to pull precompiled caches, and share those for the same version of libraries... this would also benefit CI, as all CI runs to be based off this.
  - pjmlp 9y ago
    Turbo Pascal 5.5 was compiling 34,000 lines/minute. https://edn.embarcadero.com/article/20803 https://edn.embarcadero.com/article/20803 And even today Delphi 10 is quite fast. Same applies to many other compiled languages with modules.
    - bluejekyll 9y ago
      I haven't worked with Pascal since 1999, I remember it being a much simpler language. And no where near as fun. Hilarity ensued when I didn't realize there was no garbage collector.
WatchDog 9y ago
Is it as fast as javac? Maybe on a line of code basis, but I imagine java is much simpler to to implement incremental compilation with. Since sources map pretty much 1 to 1 with classes, you mostly only need to recompile the class that changed.
- swsieber 9y ago
  Unfortunately, it's not quite that easy since java inlines constants, plus you have to account for package protected, inherited methods, etc. that you don't have to implicitly import. But really, it's the constants that make incremental compilation slower...
hyperpape 9y ago
Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini. I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times it's worse.
- vvanders 9y ago
  Mostly gut feeling :). To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.
  - fnord123 9y ago
    Maven takes a long long time to start up, but once it's ready, javac is pretty quick. Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air). I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath<T> and AsRef<T>, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)
    - wtetzner 9y ago
      > Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!) I always thought `cargo new` should have been called `cargo cult`.
  - pjmlp 9y ago
    So better try again with straight javac, Ant and Maven. Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse? http://androidbackstage.blogspot.de/2017/04/episode-64-gradleweiss.html http://androidbackstage.blogspot.de/2017/04/episode-64-gradl... https://www.youtube.com/watch?v=BKRK4SvMtRk https://www.youtube.com/watch?v=BKRK4SvMtRk The Android Gradle plugin being slow as molasses is a typical discussion theme at Google IO since it was introduced. Being partially written in Groovy also doesn't help.
amorphid 9y ago
When you compile Java from the command line, is the compiler smart enough to not recompile files that haven't changed? Or is that an IDE feature?
- cytzol 9y ago
  javac itself doesn't do any incremental compilation and will happily compile over your .class each time (though you can tell it not to; see http://stackoverflow.com/q/8271282 http://stackoverflow.com/q/8271282) Build tools like Maven and Gradle, as well as IDEs' internal build tools, will be smart and compile only the changed files.
pjmlp 9y ago
I wish it would be on par with javac, but my experience compiling rustfmt, rustsym and racer tells me otherwise. Also a bit disappointed when compared with other languages that support modules, specially the ones whose toolchains support binary dependencies. Not everyone has a high end development workstation. I am however confident the experience will eventually improve.

brandur 9y ago

I was partly relying on the context offered by the article and my parent comment to imply that sure, Rust's compiler isn't the fastest in class, but the team has identified speed as a major outstanding problem and is working very actively to address it. Compilers are pretty hard. Languages like C and Go are able to short circuit the problem by having a simplistic type system, but the Rust team's main option here is hard work, and so far they seem to be more than willing to engage in it. > At best it can beat C++ compilers - C++ being a language whose build times people love to bemoan - but usually it does far worse. Citation needed on that one. How can you even make that kind of comparison fairly?

nickpsecurity 9y ago
It's one of those things that's happened to so many people with so many C++ compilers on projects of any significant size that almost everyone says it. Happened to me with several where I moved from a Pascal-like language to find the compile time terribly slow even when I barely used the language. A lot of it is do to how the language's syntax, semantics, and esp templating are designed. Plenty of languages with even more flexibility compile faster than C++ due to better design.
- brandur 9y ago
  Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.
  - nickpsecurity 9y ago
    Maybe I misread as I quickly moved through the thread. It does look ambiguous now. All I'll claim is horrible compile times on C++. I'm not sure where Rust is at now.
    - pjmlp 9y ago

kibwen 9y ago

> but usually it does far worse Cite a source? This isn't my experience at all, Rust is still way faster at compilation than C++ on average. The advantage that C++ currently has is ccache which helps avoid needless rebuilds (which pairs well with C++'s smaller compilation units relative to Rust); building this behavior into the compiler is part of what the incremental compilation initiative is addressing.

lumpypua 9y ago
https://michaelfairley.com/blog/i-made-a-game-in-rust/ https://michaelfairley.com/blog/i-made-a-game-in-rust/ > It consists of ~7700 lines of Rust ... > Compile times with Rust are Not Great. This is easily my single biggest gripe about Rust right now. The build for A Snake’s Tale takes 15+ seconds, which makes iterating rather tedious. The current incremental compiler work also doesn’t seem to make the build for A Snake’s Tale’s codebase any faster.
- kibwen 9y ago
  That compile time is Not Great, but 15 seconds for 7700 lines of code isn't even close to "far worse than C++". :P If incremental compilation is showing no benefits whatsoever, then I'm guessing that time is largely attributable to linking (and I tend to doubt that 7700 lines of code is counting the basic third-party libraries that are required to create a crossplatform GUI app (but I'd love to be surprised!), which will contribute to linkage time... LLD please!).
- stevedonovan 9y ago
  For a full rebuild, that's a reasonable C++ build time for a project of this size. But full rebuilds are not representative, if the project is composed of many independent compilation units. The compilation unit in Rust is the crate, which is an exe or a library, so currently the best strategy is lots of little crates, which is not so ergonomic (heh) with Cargo. Actually, the compiler isn't the bottleneck - most of the time is LLVM codegen. So 'cargo check' is fast - the miri MIR interpreter likewise.