Incremental linking for Rust

I was just musing on how link times are still relatively slow. It seems it should be possible (in principle) to link incrementally, but as far as I know this is not yet possible( well, perhaps there are some dynamic link library possibilities, but I mean without that, or at least in an automated fashion to make it easy).

Are there any plans to do this at some point?

1 Like

Which linker are you using?

A coworker was able to get massive improvements in compile times by switching the linker. I can't remember which one he used, but it may have been LLD or Mold.

Does this affect target=wasm32-unknown-unknown compile times, or is wasm32 a different path ?

I have no idea what linker I am using, I just do "cargo build" ( on Windows or Linux ).

We use LLD by default for wasm. Mold doesn't support wasm.

Is it just adding

linker = "ld.lld"

to the end of Cargo.toml ?

No, the target spec base for wasm targets that is part of rustc sets the linker to rust-lld and the linker flavor to wasm-ld:

There's been interest in switching at least x64 msvc to lld too. I don't know if the performance gain against link.exe is as big as gnu ld (or if it's bigger?), but at least it's cross platform (though you still need the import libraries - there's further out work to get a pure rust Windows target that wouldn't, though!)

That said, you totally can do incremental builds, even in release builds (except when it's broken), just add this to your cargo.toml:

incremental = true

I think I am misunderstanding the 'we' here.

Are you saying:

  1. We (rustc) use LLD by default for wasm. You don't have to do anything.

  2. Rustc-wasm does NOT use LLD by default. We (projects bjorn3 works on) use LLD by default for wasm -- by modifying Cargo.toml.

I am interpreting it as (2), but by your last response, it sounds you meant (1).

Question: do I need to do anything for wasm-32-unknown-unknown to use LLD? If so, what ?


You don't need to do anything. LLD is the default for wasm32-unknown-unknown.


Some observations:

There is no problem developing a library crate. There tend to be not many dependencies and cargo test starts (even in release mode) in about 3 seconds on my laptop.

However a binary with substantial functionality is another story, it pulls in over 226 crates for me currently on windows, and that could grow substantially. The build time is 20 seconds on my windows laptop, which is starting to be painful. On my "tiny" Linux cloud server (with only 0.5GB memory) it is longer, about 45 seconds (due I think to limited memory, a swap file was required to avoid out-of-memory error).