‎Eating rustc's lunch by optimizing your (incremental) build time

Piotr Osiewicz

Rust is often praised for it's great tooling, rich crate ecosystem, safety features, good performance and a cute mascot; compile times are not cited as it's strength. It must be that darned borrow checker that's taking a lot of time, right?

No, not really. Yes. Maybe. It depends. What we all experience each day while waiting for builds does not have one grand reason - it is a sum of thousands cuts that ends up making you drum your fingers, walk away to make coffee or go for a jog.

This talk is about a mental model for compile time optimizations; where and how do you even start optimizing? What can you even reasonably optimize?

We will look at both the build system (cargo) and the compiler (rustc). This includes, but is not limited to:

‎ ‎

- How does cargo decide what to build and when?

- How are monomorphizations shared by builds of different crates?

- How can I prevent excessive monomorphizations in the first place?

- Actually, are excessive monomorphizations even a problem for me?

- What even is the problem of my build? How do I find out?

‎ ‎

‎

‎

‎ ‎

‎

Piotr Osiewicz is a software engineer working on developer tools @ Zed Industries; he likes dabbling with build tools, language servers and profilers. He strongly believes in fixing things that are not broken in the first place.