This content originally appeared on DEV Community and was authored by Luca Barbato
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
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
===============================================================================
Then I looked a bit further and I saw:
[profile.release]
codegen-units = 1
lto = true
panic = "abort"
strip = true
Definitely not friendly if you want a fast release build
-
codegen-units = 1may generate a bit more optimal code but then you can use only 1 core and if you have many... -
lto = truetends to take lots of time for some optimality, butlto = "thin"exists and the tradeoff tends to be very good, forrav1eon 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
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"]
in ~/.cargo/config.toml may be optimal at least right now.
This content originally appeared on DEV Community and was authored by Luca Barbato
Luca Barbato | Sciencx (2024-08-30T15:12:40+00:00) Is cargo/rustc that slow?. Retrieved from https://www.scien.cx/2024/08/30/is-cargo-rustc-that-slow/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.