Improving compile times for the editor

[lmsonic]

(yes i know i should use a branch instead of main, i will do it next time sorry)
I'm trying some strategies to improve the compile time, both clean build and iterative, these are the ones that i'm going to try

my system specs:
Windows 10
Processor 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz 2.30 GHz
Installed RAM 16,0 GB (15,8 GB usable)
Storage 932 GB SSD NVMe Samsung SSD 970 EVO Plus 1TB, 477 GB SSD NVMe SAMSUNG MZVL2512HCJQ-00B07
Graphics Card NVIDIA GeForce RTX 3060 Laptop GPU (6 GB), Intel(R) UHD Graphics (128 MB)
System Type 64-bit operating system, x64-based processor

• add cargo .config file to add lld as a linker, and add clang to the workflows to make them pass
  clean build
  main: 2m 16s
  with lld: 2m 23s
  incremental build (changing a string of the name component in bevy_editor)
  main: 14.5s~
  with lld: 10.5s~

• enable dynamic linking -> needs optimization 3 on windows and would nuke CI so no
  clean build:
  with dynamic linking: 9m 28s
  incremental build(same as above):
  at best 5s but its getting 30s depending how much is in contention with clippy aaaaaa my computer is screaming

• trying to add no-default-features to as much dependencies as possible and re-add necessary features to cargo toml
  I don't see any dependencies that would be able to be trimmed easily

• remove unused or empty crates
  clean build
  2m 20s
  incremental build(same as above):
  10.5s~ more or less same as above

• document how to use hot-patching

[mockersf]

It should not be needed to install a custom linker to contribute

And the recommended config is https://github.com/bevyengine/bevy/blob/main/.cargo/config_fast_builds.toml

[janhohenheim]

Agreed with @mockersf, I would leave this renamed so that it is opt-in for users. What I do personally is enable it for CI/CD, so that new release builds are available faster.

Also, it would be good to follow the file linked in n the Bevy repo. It could be improved some more, I just didn't submit a PR yet :) For example, you can cut down compilation times by about 50% by using cranelift.

Lastly, its worth considering also enabling dynamic linking, but doing that reliably automatically out of the box for debug builds only would require using the Bevy CLI alpha and adding a metadata line to the Cargo.toml, telling the CLI which features to use in debug and which to use in release.

Ping me if you need help with any of these steps :)

[lmsonic]

I tested the file config_fast_builds.toml in nightly on Windows with these settings, by also adding cranelift by using the file you posted on discord as a template. It makes sense to keep it opt in by using a renamed file. @janhohenheim For enabling it only in CI, how would it be done? Rename the config_fast_builds.toml file to config.toml in the workflow?

It might make sense to reopen another PR with just this if the other changes that I made are unwanted.

clean build
1m 45s
incremental build
5s ~

[target.x86_64-pc-windows-msvc]
# LLD linker
#
# You may need to install it:
#
# ```
# cargo install -f cargo-binutils
# rustup component add llvm-tools
# ```
linker = "rust-lld.exe"
rustdocflags = ["-Clinker=rust-lld.exe"]
rustflags = [
    # Nightly
    "-Zshare-generics=n", # This needs to be off if you use dynamic linking on Windows.
    "-Zthreads=0",
]

# Cranelift
[unstable]
codegen-backend = true

[profile]
incremental = true

[profile.dev]
codegen-backend = "cranelift"
# If you want to attach a debugger, set this to true
debug = "line-tables-only"

# Consider compiling deps with cranelift if you want cold-compilation to be faster
[profile.dev.package."*"]
codegen-backend = "cranelift"

# cranelift is `panic = abort`, so you need to compile with llvm to get `#[should_panic]` working
[profile.test.package."*"]
codegen-backend = "llvm"

# Disable cranelift for release profile
[profile.release]
codegen-backend = "llvm"

[janhohenheim]

That file looks good for Windows!
On Linux, you could use mold, but the speedup compared to LLD is in the range of single seconds. That's noticeable on a local incremental build, but not on CI, where you need to download mold first.

For CI, I indeed just rename the file in a workflow step. Just be VERY careful about not using any rustflags in the env vars, or your config.toml rustflags will be ignored. This is a huge footgun for CI. Only set rustflags in the CI's config.toml

If this repo has no should_panic, you can safely set the backend to cranelift for the test profile. Doing so is a huge speedup for cargo test. Speaking about it, if running tests takes a while, nextest is much faster and tends to give better error messages for failed tests. If you want to add that to the CI, you can install it with cargo binstall to not have to compile it first.

Lastly, Linux and macOS can gain extra speed from sharing generics, but you probably noticed that :)