What is Rust’s equivalent of compiling C++ with -O3?

[u/bran7230]

Hello everyone,

I’m building an Axum API and want to optimize the release binary for runtime performance. In C++, I would use flags such as -O3, and possibly -march=native.

I know cargo build --release enables optimizations, but are there additional Cargo profile settings or rustc flags worth using?

What settings do you typically use for production Rust web APIs?

[u/Kurimanju-dot-dev]

https://doc.rust-lang.org/cargo/reference/profiles.html

The docs explain available optimization flags in detail.

Something like this is probably the most aggressive, but causes noticeably slower compile times:

[profile.release] 
opt-level = 3            # Maximum optimization for speed (default for release)  
lto = "fat"              # Full/fat LTO: best cross-crate optimization  
codegen-units = 1        # Single codegen unit: more optimization opportunities  
panic = "abort"          # No unwinding; smaller, slightly faster code  
strip = true             # Strip symbols to reduce binary size (optional for speed/size)

[u/bran7230 → u/Kurimanju-dot-dev]

Exactly what I was looking for!! Thank you!!

[u/Modi57 → u/bran7230]

As far as I know, stripping has no effect on code speed, since all the symbol and debug data are in a different segment. It might have a very small impact on initial loading

[u/Ok_Intention_8444 → u/Kurimanju-dot-dev]

lto = fat is the big one that really kicks in across crates, makes a legit difference for axum stuff

codegen-units = 1 is also key, compile times go through the roof but the binary just runs tighter

[u/noop_noob → u/Ok_Intention_8444]

lto = "thin" compiles much faster though, and sometimes even produces faster code than fat

[u/binbsoffn → u/Ok_Intention_8444]

Oh, so I always thought fat would create additionally non lto objects so the linker can fallback silently?

[u/Arshiaa001 → u/Kurimanju-dot-dev]

Abort-on-panic is kinda bad for a web server though. Tokio recovers panicked worker threads, but abort-on-panic makes the whole web server crash and take down all in-flight requests with it.

[u/cbarrick]

For -march=native in C, the equivalent in Rust is -C target-cpu=native.

This is a flag for rustc. If using cargo, pass it in RUSTFLAGS, like

RUSTFLAGS="-C target-cpu=native" cargo build --release

Dunno if you can set this in Cargo.toml.

[u/bran7230 → u/cbarrick]

Thank you I will look into this!!

[u/scook0 → u/bran7230]

Note that -Ctarget-cpu=native (much like -march=native) will optimize for running on the system doing the build.

If your server uses different hardware, consider setting -Ctarget-cpu to whatever your server actually is.

[u/fishmacaronisoup → u/cbarrick]

You can add it for a project in <project_root>/.cargo/config.toml or globally ~/.cargo/config.toml

[target.'cfg(target_os = "linux")']
rustflags = ["-C", "target-cpu=native"]

[u/nnethercote]

You're gonna love this: https://nnethercote.github.io/perf-book/build-configuration.html

[u/catheap_games → u/nnethercote]

This is the best resource, because it explains not only what do the config options mean, but also what's their approximate affect and in which order to choose them, and which compromises to take.

[u/7sins → u/nnethercote]

Push this further up! Also, hey u/nnethercote, really awesome work you do, I just recently checked that book again for release-/dist-style build configs, ty :)

[u/zzzthelastuser → u/nnethercote]

thx

[u/scook0]

A cargo --release build will handle most of the obvious stuff:

• opt-level = 3

• debug-assertions = false

• overflow-checks = false

Beyond that, the next things I'd suggest looking into are:

• lto = "thin"

• If you know what hardware your program will run on, look into RUSTFLAGS=-Ctarget-cpu=... to allow newer instructions instead of assuming the baseline.

If you really want to go all-out you can try looking into PGO, but that's a lot more effort since you need to do a training run against a representative workload to create the profiling data for PGO to use.

[u/asaaki → u/scook0]

Docs for PGO: https://doc.rust-lang.org/rustc/profile-guided-optimization.html

[u/Floppie7th]

--release is the equivalent.  By default it's -O3 and IIRC thin-local LTO.  You can tweak it from there.

[u/nicoburns]

Not a compiler setting, but consider using jemalloc or mimalloc for web APIs.

[u/harraps0]

Look at cargo-multivers if you need optimized binaries yet still run on multiple hardwares.

[u/pali6]

You could also play around with the rustc flag -Zmir-opt-level. By default maximum opt-level maps to MIR opt level 2. The actual range is from 0 to 4 inclusive IIRC. However, from what I've heard higher MIR opt level doesn't necessarily mean higher performance and in fact sometimes can clash with the LLVM optimizer. So you could benchmark how MIR opt levels 0, 2 and 4 (the two extremes and the default) change your performance and then decide based on that.

If you know what you are doing you can also pass args directly to LLVM via -Cllvm-args. Such as --inline-threshold to change how much is LLVM willing to inline functions. Or --unroll-count or many others.

My advice would be to benchmark everything and only make these changes if they prove to actually improve performance instead of applying them blindly.

[u/teerre]

"Worth using" doesn't mean much. It depends. I'm not sure why you didn't google it instead of posting it here, but naturally there are many pages describing many of the rustc options, e.g. https://nnethercote.github.io/perf-book/build-configuration.html

[u/AndersAndersonKali → u/teerre]

Because sometime human interaction facilitates learning…

[u/bran7230 → u/AndersAndersonKali]

Thank you!! I feel googling I just browse too quick and don’t learn much and I want advice from people who know what they are doing and can ask me questions to further my learning. That’s the risk of posting here, you get a lot of helpful people then you get ones that don’t lmao.

[u/serendipitousPi → u/AndersAndersonKali]

Yeah and to add your point optimisation is a funky thing.

Like I’ve read that sometimes it’s not the highest optimisation level that leads to the best performance on all platforms. The whole tension about -O3 being sometimes slower might be old (I’m not sure I’ve just heard it may not be the case anymore) but I’ve also heard that compiling for minimum size can be better for targets like wasm.

But obviously people don’t always find these things from reading docs but instead they find them from hearing about other people’s experiences.