Improve performance of `cargo build` whenever `src` changes by one order of magnitude.

[tontinton]

This is the first rust project I opened where I need to get out of battery saver mode into high performance mode.

Even then, making a save and then waiting 5+ seconds until rust analyzer gives me feedback is way too long, I have no idea how you manage to keep working like this.

The solution is to separate as much as possible into subdirs, so that src will not need to compile the entire crate when saving a file.

WDYT?

[ssddOnTop]

Will need to move cli anyways

[bnchi]

My rust analyzer isn't that slow on neovim it's quite fast after the initial startup

[tusharmath]

@tontinton I don't know about you about build-time is like weight gain. You don't realize that you have gained weight unless you meet a friend after a long time and they tell you.

I would love to shed some weight! Here is the initial report of cargo build --timings hopefully someone can take it from here.

cargo-timing-20240713T095153Z.html.zip

[tusharmath]

Steps

# Clean the project
cargo clean 

# Create first build
cargo build # 1-2 mins

# Modify a file
touch src/lib.rs

# Create second build
cargo build # Current: 6-7 secs, expected <600ms

Requirements

• There should be a 10x improvement in the build performance of the second run.
• Update contribution guidelines for improving build times.

[bnchi]

Steps

# Clean the project
cargo clean 

# Create first build
cargo build # 1-2 mins

# Modify a file
touch src/lib.rs

# Create second build
cargo build # Current: 6-7 secs, expected <600ms

Requirements

* There should be a 10x improvement in the build performance of the second run.

* Update contribution guidelines for improving build times.

I'm going to give this a shot hoping this will improve my workflow not sure about the 10x but any gains are good :p

[tusharmath]

Hope you wouldn't mind a tip if there is a realistic improvement in performance ;)

[webbdays]

@tusharmath

[profile.dev] opt-level = 0 codegen-units = no_of_processors incremental = true lto = false

These compiler options helped with decreasing 2nd build time from around 14 to around 10 secs. It also changes when we choose different number of codegen-units. So, it seems one need to pick the right number depending on the codebase and their computer.

[tusharmath]

@webbdays Feel free to create a PR. It's a good starting point.

[bnchi]

I'm still doing some analysis, one of the things that I saw in the flamegraph report for my machine was that tailcall binary crate linking is taking a big chunk of the time, if anyone is using linux they can try out mold, on macos most likely(I don't use a mac) you can try out lld linker if it's not a default.

[bnchi]

Link for mold https://github.com/rui314/mold

[karatakis]

I tried both with mold (clang) and without. With mold, you can achieve a ~2x improvement (on my laptop)

normal-clean-build:

mold-clean-build:

normal-rebuild:

mold-rebuild:

[bnchi]

If anyone is interested in a better/faster development experience on tailcall, I'm using bacon now for code checks and switched off rust analyzer checks and kept it to help me jump between definitions, references etc ...

cargo check is a lot more faster than RA hence the improvement in dev time for me.

https://github.com/Canop/bacon

[github-actions[bot]]

Action required: Issue inactive for 30 days. Status update or closure in 7 days.

[github-actions[bot]]

Issue closed after 7 days of inactivity.