5 ms·

10 minutes to compile? Intense.

jacquesm 6y ago
It's one of the reasons I both love and hate interpreted languages: they're by far the fastest edit-test cycle available so they are super fast to get started but after a while and when your program becomes larger you always end up wishing you had more goodies to keep you from messing up.
- brundolf 6y ago
  As I wrote in another comment, Rust's edit-test cycle is actually quite respectable thanks to the build cache. I've personally worked on a Rust web server with several significant-sized libraries, including Serde which was mentioned in the article as being pretty large, and turnaround time was 1-2 seconds for small edits to my own code (including the server startup time). I kept a watch script running that rebuilt and restarted on each change, and the experience was comparable to Express.
- josephg 6y ago
  Me too! Its weird to me that people justify slow compilation times by pointing out how much work the compiler needs to do. And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. I really hate that I needed to do this, but I recently acknowledged that my 2016 macbook pro just isn't fast enough for rust development to feel good. I replaced it with a ryzen 5800 based desktop workstation for dev work. With my new machine a full build of a rust project I've been working on dropped from 2 minutes down to 20 seconds. Its an absolute delight and I highly recommend doing the same if you're writing rust regularly and can afford it. Hopefully the next few years of CPU improvements will forgive our collective inability to engineer CPU-efficient compilers.
  - zozbot234 6y ago
    > And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. Along these lines, Rust developers are working on adopting cranelift (a compiler framework used for JIT in Firefox) for quick debug builds, where runtime performance is not critical.
  - hderms 6y ago
    I don't know for certain but I believe it's mostly slow because of traits, lifetime/borrow checker, etc... The compiler is basically a proof system and would be doing work that's hard to compare to V8
    - deleted 6y ago
      [deleted]
    - josephg 6y ago
      Sure ... My question is, what do you think the upper bound on performance is for a performance-oriented rust compiler? Like, if the whole compiler were written to optimize the edit-build-run cycle, how many times faster could it go? Exhibit A, in our recent history of compilers we've had lots of examples of compilers / runtimes which seemed like they were pretty close to the threshold, only for another compiler to come out of nowhere and compile many times faster. Examples: (everything before V8) -> V8, Lua -> LuaJIT, Gcc -> clang (when it was new). And this is cheating but I'm doing it - every C compiler -> Go's compiler. So the question is, how surprised would you be if some serious, experienced compiler people were capable of making a rust compiler that was 3x faster than rustc? Personally I would be not surprised at all. I suspect a lot of rustc's slowness comes from a combination of unavoidable time spent in llvm plus all the work rustc needs to do to convert rust to llvm IR. Its a bit of a smoking gun that most compilers built on top of llvm are pretty slow - swift, c++, rustc, pony, etc. And all the fast compilers have their own backend (go, v8, luajit, jai, etc). So yeah, I'm hopeful for MIRI and cheering from the sidelines.
      - hderms 6y ago
        I think that's totally valid, especially because there are likely tons of bottlenecks that make the entire process slower than it otherwise could be. I just think there are some challenges to compiling Rust that might make the upper bound of efficiency less than desired
- Const-me 6y ago
  Golang and C# are compiled, yet they both compile fast enough so you unlikely gonna notice compilation time in your edit-test workflow. No practical differences from interpreted languages.
  - Skunkleton 6y ago
    Go's deployment story is pretty great too.
  - jacquesm 6y ago
    In the case of Go, the language was to some extent designed to be fast to compile.
zucker42 6y ago
I'm curious if the author used incremental builds and what hardware exactly was used.
- tmcw 6y ago
  The post mentions this, but the main concern is continuous deployment, where cache doesn’t really help - you’re building from scratch at least once, and the build isn’t happening on your MacBook or fancy development machine but on Google cloud build or some other time & resource-limited environment.

It's one of the reasons I both love and hate interpreted languages: they're by far the fastest edit-test cycle available so they are super fast to get started but after a while and when your program becomes larger you always end up wishing you had more goodies to keep you from messing up.

brundolf 6y ago
As I wrote in another comment, Rust's edit-test cycle is actually quite respectable thanks to the build cache. I've personally worked on a Rust web server with several significant-sized libraries, including Serde which was mentioned in the article as being pretty large, and turnaround time was 1-2 seconds for small edits to my own code (including the server startup time). I kept a watch script running that rebuilt and restarted on each change, and the experience was comparable to Express.
josephg 6y ago
Me too! Its weird to me that people justify slow compilation times by pointing out how much work the compiler needs to do. And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. I really hate that I needed to do this, but I recently acknowledged that my 2016 macbook pro just isn't fast enough for rust development to feel good. I replaced it with a ryzen 5800 based desktop workstation for dev work. With my new machine a full build of a rust project I've been working on dropped from 2 minutes down to 20 seconds. Its an absolute delight and I highly recommend doing the same if you're writing rust regularly and can afford it. Hopefully the next few years of CPU improvements will forgive our collective inability to engineer CPU-efficient compilers.
- zozbot234 6y ago
  > And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. Along these lines, Rust developers are working on adopting cranelift (a compiler framework used for JIT in Firefox) for quick debug builds, where runtime performance is not critical.
- hderms 6y ago
  I don't know for certain but I believe it's mostly slow because of traits, lifetime/borrow checker, etc... The compiler is basically a proof system and would be doing work that's hard to compare to V8
  - deleted 6y ago
    [deleted]
  - josephg 6y ago
    Sure ... My question is, what do you think the upper bound on performance is for a performance-oriented rust compiler? Like, if the whole compiler were written to optimize the edit-build-run cycle, how many times faster could it go? Exhibit A, in our recent history of compilers we've had lots of examples of compilers / runtimes which seemed like they were pretty close to the threshold, only for another compiler to come out of nowhere and compile many times faster. Examples: (everything before V8) -> V8, Lua -> LuaJIT, Gcc -> clang (when it was new). And this is cheating but I'm doing it - every C compiler -> Go's compiler. So the question is, how surprised would you be if some serious, experienced compiler people were capable of making a rust compiler that was 3x faster than rustc? Personally I would be not surprised at all. I suspect a lot of rustc's slowness comes from a combination of unavoidable time spent in llvm plus all the work rustc needs to do to convert rust to llvm IR. Its a bit of a smoking gun that most compilers built on top of llvm are pretty slow - swift, c++, rustc, pony, etc. And all the fast compilers have their own backend (go, v8, luajit, jai, etc). So yeah, I'm hopeful for MIRI and cheering from the sidelines.
    - hderms 6y ago
      I think that's totally valid, especially because there are likely tons of bottlenecks that make the entire process slower than it otherwise could be. I just think there are some challenges to compiling Rust that might make the upper bound of efficiency less than desired
Const-me 6y ago
Golang and C# are compiled, yet they both compile fast enough so you unlikely gonna notice compilation time in your edit-test workflow. No practical differences from interpreted languages.
- Skunkleton 6y ago
  Go's deployment story is pretty great too.
- jacquesm 6y ago
  In the case of Go, the language was to some extent designed to be fast to compile.

zucker42 6y ago

I'm curious if the author used incremental builds and what hardware exactly was used.

tmcw 6y ago
The post mentions this, but the main concern is continuous deployment, where cache doesn’t really help - you’re building from scratch at least once, and the build isn’t happening on your MacBook or fancy development machine but on Google cloud build or some other time & resource-limited environment.