3 ms·

Mold is great, here are some usecases I love: 1. Faster rust builds! [target.x86_64-unknown-linux-gnu] linker = "clang" rustflags = [ "-C", "link-arg=-fuse

Mold is great, here are some usecases I love: 1. Faster rust builds! [target.x86_64-unknown-linux-gnu] linker = "clang" rustflags = [ "-C", "link-arg=-fuse-ld=mold", "-C", "target-cpu=native" ] 2. Faster `makepkg` with ArchLinux, by adding "-fuse-ld=mold" to CFLAGS.

forrestthewoods 3y ago
What was the before/after on your Rust link times?
- ripley12 3y ago
  About a year ago, I was seeing incremental builds go from ~8s to ~2.7s with Mold. Huge quality of life improvement. (fairly large Rust project, 24-core machine, Linux)
- Measter 3y ago
  A quick and dirty comparison on my project: -- GNU Ld 2.31.1 >> cargo build --release Compiling mfl v0.1.0 (/mnt/d/Programming/Projects/Rust/mfl/crates/mfl) Finished release [optimized + debuginfo] target(s) in 10.14s -- LLD-14 >> cargo build --release Compiling mfl v0.1.0 (/mnt/d/Programming/Projects/Rust/mfl/crates/mfl) Finished release [optimized + debuginfo] target(s) in 6.20s -- Mold 2.0 >> cargo build --release Compiling mfl v0.1.0 (/mnt/d/Programming/Projects/Rust/mfl/crates/mfl) Finished release [optimized + debuginfo] target(s) in 6.02s I did the following for each test: cargo clean cargo build --release touch crates/mfl/src/main.rs cargo build --release With the timings coming from the second build. The project links in LLVM, and the tests were done under WSL1 on Windows 10 with the files on the Windows file system, which is how the project is developed in general.
- aseipp 3y ago
  Personal anecdote: linking a debug build of buck2 (big Rust codebase) went from 30s to 3s for me. Pretty wonderful.
rmdashrfstar 3y ago
How does this latest release compare to lld? Can it run on alpine/musl?
unshavedyak 3y ago
Is there a way to override this linker setting only for your local install? Ie i don't want to change production code or binaries, but it would be nice to have faster builds
- themulticaster 3y ago
  Yes, it should just work for all projects if you put in in ~/.cargo/config.toml, or as a per-project setting. Git life pro tip (that you didn't know you needed until now): You can use .git/info/exclude (present in every Git repository) as a local, private version of .gitignore. It has the same syntax as .gitignore, but isn't tracked by Git. So you could add .cargo/config.toml to .git/info/exclude, changing the linker locally without Git considering it as an untracked file. I generally use this feature to ignore files that are specific to my development setup which I don't want to list in .gitignore.
  - maximilianroos 3y ago
    Great tip! Didn't know about this. A similar one: ~/.config/git/ignore is a global private gitignore. Great for files across repos which you always want to ignore, such as temporary files from an editor
  - unshavedyak 3y ago
    Some projects add project/.cargo/config.toml which is unfortunate, but cool to learn about a global config for this purpose! Ty

forrestthewoods 3y ago

What was the before/after on your Rust link times?

ripley12 3y ago
About a year ago, I was seeing incremental builds go from ~8s to ~2.7s with Mold. Huge quality of life improvement. (fairly large Rust project, 24-core machine, Linux)
Measter 3y ago
A quick and dirty comparison on my project: -- GNU Ld 2.31.1 >> cargo build --release Compiling mfl v0.1.0 (/mnt/d/Programming/Projects/Rust/mfl/crates/mfl) Finished release [optimized + debuginfo] target(s) in 10.14s -- LLD-14 >> cargo build --release Compiling mfl v0.1.0 (/mnt/d/Programming/Projects/Rust/mfl/crates/mfl) Finished release [optimized + debuginfo] target(s) in 6.20s -- Mold 2.0 >> cargo build --release Compiling mfl v0.1.0 (/mnt/d/Programming/Projects/Rust/mfl/crates/mfl) Finished release [optimized + debuginfo] target(s) in 6.02s I did the following for each test: cargo clean cargo build --release touch crates/mfl/src/main.rs cargo build --release With the timings coming from the second build. The project links in LLVM, and the tests were done under WSL1 on Windows 10 with the files on the Windows file system, which is how the project is developed in general.
aseipp 3y ago
Personal anecdote: linking a debug build of buck2 (big Rust codebase) went from 30s to 3s for me. Pretty wonderful.

rmdashrfstar 3y ago

How does this latest release compare to lld? Can it run on alpine/musl?

unshavedyak 3y ago

Is there a way to override this linker setting only for your local install? Ie i don't want to change production code or binaries, but it would be nice to have faster builds

themulticaster 3y ago
Yes, it should just work for all projects if you put in in ~/.cargo/config.toml, or as a per-project setting. Git life pro tip (that you didn't know you needed until now): You can use .git/info/exclude (present in every Git repository) as a local, private version of .gitignore. It has the same syntax as .gitignore, but isn't tracked by Git. So you could add .cargo/config.toml to .git/info/exclude, changing the linker locally without Git considering it as an untracked file. I generally use this feature to ignore files that are specific to my development setup which I don't want to list in .gitignore.
- maximilianroos 3y ago
  Great tip! Didn't know about this. A similar one: ~/.config/git/ignore is a global private gitignore. Great for files across repos which you always want to ignore, such as temporary files from an editor
- unshavedyak 3y ago
  Some projects add project/.cargo/config.toml which is unfortunate, but cool to learn about a global config for this purpose! Ty