No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to.

(I know that compilation speed is a Hard Problem, I know that I'm comparing apples to oranges, I know that Rust does fancy magic that other languages could only dream of. But everything that slow compiles buy me won't get bring me back flow state.)

If it is a project you’ve recently built, it shouldn’t matter what’s in your cargo file, since none of that will change from build to build. I wonder what’s broken. How long does it take to build a new empty project?

One think that’s helped me stay “in the flow” is switching to rust-analyzer instead of the current official RLS. Much faster, I leave format on save turned on, so `cargo check` output is usually ready in about a quarter of a second after save.

A new empty project compiles in under a second. However, adding dependencies will add some arbitrary number to this. Additionally, every hundred lines of code seems to add some amount of time between half a second and a whole second. I did some reading and read that generics are particularly expensive to compile, so I wonder if that accounts for the variance. I can't explain why cargo deps add time, though.

I LOVE rust-analyzer. It's actually what got me to reconsider Rust after I tried a year or two ago, and it is SO good.

Let me put it a stronger way: if you're seeing your cargo dependencies recompile every time, it is a bug. Please file one upstream. These bugs do happen, but they are bugs.

I don't literally see my deps compile. It's just that compile time gets slower. (I wonder if it's related to the linker?) Is that still a bug? Would be happy to report it if so.

If the slowless you're seeing is caused by the linker, which can very well be the case, consider using LLD as you can see significant speed improvements to the linking step.

https://github.com/rust-lang/rust/issues/39915#issuecomment-...

https://doc.rust-lang.org/1.22.0/unstable-book/compiler-flag...

If installed, you can run

    RUSTFLAGS="-Clink-arg=-fuse-ld=lld" cargo build --release

Looked into this :) unfortunately I run Mac so there's nothing I can do here. Tempted to dual boot Ubuntu, though.

It's a shame. I'm on the same boat and not being able to use lld adds a literal minute to my builds :-/

Ahh.

I am less sure, but I would think that's expected, given that it has to link everything together into the final binary. You're gonna end up giving the linker more work to do, as you suspected.

What? I have a ~1k LOC program which consists of 4 modules, 3 of them all importing the 4th and in total ~200 dependencies. With a warm cache my program takes ~2s to compile. Cold-cache is about 18s

Interesting! I wonder if I was hitting some pathological case with my dependency tree.

Rust compilation times as they stand today are actually worse than C++. C++ also offers flexibility to an engineer to reduce compilation times significantly via use of techniques like shared headers, etc.

> I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml.

Why compile again after adding a comment?

In fast-compiling languages, it's viable to have recompile-on-file-save or even continuous recompilation. Modern (and they aren't that modern anymore) IDE's will show red squiggles under code with compilation errors without requiring any action at all.

That's already provided by other tools than the compiler like rust analyzer.

This was meant as an example, not something I'd literally do.

The most common trivial change would be to add a dbg! statement.

Build systems usually don't care what you added. Modification of source means rebuild.

Yes, but the programmer knows what they added, and I was asking why they wanted to build again if all they added was a comment? If this was in a CI context then 10 seconds seems unimportant; compile times of 10 seconds are usually only complained about in the context of programmers who've gotten used to tiny edit-compile-test cycles.

In order to ensure the next rebuild on an actual code change doesn't need to compile this comment-changed file, I guess.