DEV Community

Luca Barbato
Luca Barbato

Posted on

Is cargo/rustc that slow?

#rust #cargo

As a side-discussion from the ongoing mess I read this about Waiting 15 minutes for a small program, e.g. like Yazi to compile is wild.

I tried and on my laptop took about 2 minutes to build in release mode, not too bad.

❯ cargo build ... Finished `dev` profile [unoptimized + debuginfo] target(s) in 27.51s ❯ cargo clean ❯ cargo build --release ... Finished `release` profile [optimized] target(s) in 2m 01s
Enter fullscreen mode Exit fullscreen mode

yazi isn't exactly a small program:

❯ cargo tree | grep -v yazi | wc -l 685 ❯ tokei =============================================================================== Language Files Lines Code Comments Blanks =============================================================================== JSON 1 1 1 0 0 Lua 34 1973 1639 31 303 Markdown 2 207 0 149 58 Nix 4 270 235 6 29 Shell 3 56 41 6 9 TOML 18 1819 1484 128 207 YAML 1 33 29 1 3 ------------------------------------------------------------------------------- Rust 463 27288 22926 280 4082 |- Markdown 6 56 0 51 5 (Total) 27344 22926 331 4087 =============================================================================== Total 526 31647 26355 601 4691 ===============================================================================
Enter fullscreen mode Exit fullscreen mode

Then I looked a bit further and I saw:

[profile.release] codegen-units = 1 lto = true panic = "abort" strip = true
Enter fullscreen mode Exit fullscreen mode

Definitely not friendly if you want a fast release build

  • codegen-units = 1 may generate a bit more optimal code but then you can use only 1 core and if you have many...
  • lto = true tends to take lots of time for some optimality, but lto = "thin" exists and the tradeoff tends to be very good, for rav1e on x86_64 for a long while managed to produce even a better binary.

So what happens if I do those changes?

❯ cargo build --release ... Finished `release` profile [optimized] target(s) in 47.05s
Enter fullscreen mode Exit fullscreen mode

I guess sometimes it is better to not stop at the first program to evaluate if a toolchain is fast or slow :)

P.S.

If you are on Linux, at least right now the quickest combination seems to be clang as linker with mold doing the actual work.
gcc + mold seems sensibly slower and clang + ld.bfd is curiously a tad slower than gcc + ld.bfd.
Setting

[target.{yourarch}] linker = "clang" rustflags = ["-C", "link-arg=-fuse-ld=mold"]
Enter fullscreen mode Exit fullscreen mode

in ~/.cargo/config.toml may be optimal at least right now.

Top comments (0)