The book · Appendix

Fast compiles

You change one line, you want to see it, and you wait. What you wait for is a rebuild: Cargo compiling what changed and joining it to the rest, a job called linking. It's the wait you'll meet a hundred times a day, so it's the one that matters. A game made with shuyi new rebuilds in about a second, on the stable Rust it pins:

A clean build compiles everything, the engine included, as your first build does. cargo check looks for errors and doesn't make a program, which is why it's so quick. MSVC and GNU are Rust's two toolchains on Windows (chapter 1).

Linux and Windows (MSVC) are GitHub's 4-core runners; Windows (GNU) is a 24-core desktop. The engine's CI measures a new game's rebuild on every change to the engine, and fails one that goes over its budget.

The setup

You don't need to do anything for this: it comes with a new game. It is in the root Cargo.toml, whose comments say the same, and you can read on if you want to change it.

• No debug info in dev builds (debug = false). dev is the build cargo run makes, and debug info is the extra data a debugger reads. Leaving it out takes about a third off each rebuild. A panic still names its file and line; set debug = "line-tables-only" for lines in backtraces, the list of what was running when it stopped, or true for a debugger.
• The engine and every other crate built optimized (opt-level = 2 for "*"), so the game runs at speed in a debug build. They rarely change, so you pay for that once. Level 1 makes no rebuild faster.
• The linker Rust picks. On Linux, Rust's own rust-lld has been the default since Rust 1.90, and mold is no faster. On Windows with the GNU toolchain, rust-lld can't read the import libraries a game links, so MSYS2's linker stays; with MSVC, rust-lld is no faster than link.exe.
• Incremental builds of the game's own crates, cargo's default for dev, which reuse what didn't change: without them a rebuild takes 10 to 50 % longer.

Linking the engine as one dynamic library, a file loaded when the program starts, as Bevy's dynamic_linking does, made no rebuild faster: the engine's crates are few and already built, so linking them statically, into the program, costs little.

When it's slow

• The first build takes minutes. That's the clean build, and it happens once per folder, and again when you change the Rust version, or run cargo clean.
• A rebuild takes much longer than the table. See whether you added a dependency, which has to compile too, and whether you changed debug or an opt-level. cargo build --timings writes a page saying where the time went.
• cargo run --release is slow to build. A release build is the one you ship: it optimizes everything, so it takes a lot longer. Use it for shipping, and for measuring speed.

On a nightly toolchain

Nightly is the Rust that's built each night, with features not yet finished. Two more options may help, for a developer to try in their own .cargo/config.toml: the Cranelift backend (-Zcodegen-backend=cranelift, with the rustc-codegen-cranelift component) and shared generics (-Zshare-generics=y).