Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fast build profile without debuginfo #2628

Merged
merged 1 commit into from
Mar 25, 2024
Merged

Conversation

konstin
Copy link
Member

@konstin konstin commented Mar 22, 2024

Add a compile option -p fast-build for a 16% incremental compile speedup (linux) at the cost of having no debuginfo.

After trying various rust compiler speedup suggestions, setting mold as my default linker and removing debuginfo are the only ones showing a speedup.

hyperfine --warmup 1 --runs 3 --prepare "touch crates/uv-resolver/src/resolver/mod.rs" \
    "cargo +nightly build --bin uv" \
    "cargo +nightly build --bin uv --profile fast-build"
Benchmark 1: cargo +nightly build --bin uv
  Time (mean ± σ):      1.569 s ±  0.008 s    [User: 1.179 s, System: 0.369 s]
  Range (min … max):    1.560 s …  1.576 s    3 runs

Benchmark 2: cargo +nightly build --bin uv --profile fast-build
  Time (mean ± σ):      1.353 s ±  0.020 s    [User: 1.109 s, System: 0.301 s]
  Range (min … max):    1.338 s …  1.375 s    3 runs

Summary
  cargo +nightly build --bin uv --profile fast-build ran
    1.16 ± 0.02 times faster than cargo +nightly build --bin uv

Add a compile option `-p fast-build` for a 16% incremental compile speedup (linux) at the cost of having no debuginfo.

After trying various rust compiler speedup suggestions, setting mold as my default linker and removing debuginfo are the only ones showing a speedup.

```
hyperfine --warmup 1 --runs 3 --prepare "touch crates/uv-resolver/src/resolver/mod.rs" \
    "cargo +nightly build --bin uv" \
    "cargo +nightly build --bin uv --profile fast-build"
Benchmark 1: cargo +nightly build --bin uv
  Time (mean ± σ):      1.569 s ±  0.008 s    [User: 1.179 s, System: 0.369 s]
  Range (min … max):    1.560 s …  1.576 s    3 runs

Benchmark 2: cargo +nightly build --bin uv --profile fast-build
  Time (mean ± σ):      1.353 s ±  0.020 s    [User: 1.109 s, System: 0.301 s]
  Range (min … max):    1.338 s …  1.375 s    3 runs

Summary
  cargo +nightly build --bin uv --profile fast-build ran
    1.16 ± 0.02 times faster than cargo +nightly build --bin uv
```
@konstin konstin added the internal A refactor or improvement that is not user-facing label Mar 22, 2024
@charliermarsh
Copy link
Member

What's the use-case for this?

@zanieb
Copy link
Member

zanieb commented Mar 23, 2024

Should we use this in CI?

@konstin
Copy link
Member Author

konstin commented Mar 23, 2024

What's the use-case for this?

A faster edit-run loop, ideally

@charliermarsh
Copy link
Member

What is the practical cost of having no debug info? (My main pushback here is: who's going to remember to set this? When should they? Should this be the default? Etc.)

@konstin
Copy link
Member Author

konstin commented Mar 25, 2024

There were several reports recently about massive speedups for debug builds using advanced or experimental cargo options: Using the parallel frontend, the cranelift backend, static musl, etc. I found that none of them worked for us except using mold (which i have in my global configuration) and removing debuginfo.

This PR adds -p fast-build to cargo commands for a speedup when changing a file i commonly work on. No debuginfo means that tracebacks will be empty and you can't use an debugger on the artifact. Since i need either rarely i find this a free 16% speedup a good tradeoff. I made this a separate profile to avoid confusing people who expect the default debug build to have panic traceback and work with their debuggers.

Should we use this in CI?

We have to try! I haven't checked how much it matters for that case

@charliermarsh charliermarsh merged commit 786598b into main Mar 25, 2024
31 checks passed
@charliermarsh charliermarsh deleted the konsti/fast-build branch March 25, 2024 20:57
@charliermarsh
Copy link
Member

Lets give it a try.

@charliermarsh
Copy link
Member

Can I make this my default somehow?

@konstin
Copy link
Member Author

konstin commented Mar 26, 2024

Can I make this my default somehow?

Except for aliases, i don't think so unfortunately

@zanieb zanieb mentioned this pull request Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal A refactor or improvement that is not user-facing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants