So... Yeah. Can/Should we add¹ an inlining pass to the set of passes that run for builds with
opt-level = 1?
Rust is really reliant on
#[inline] for perf — more so than even C++. This is true of both the stdlib code and user code. Unfortunately, inlining does not happen until
opt-level = 2. In my experience there's almost no difference in -O1 and -O0 at the moment, but you get a huge jump for -O2.
I get that it's a compile-perf hit, which is why I'm not suggesting it for -O0. I also am aware at some point in the future an MIR-based inliner may or may not solve some of this, but that doesn't preclude addressing it now.
(Currently, to get better perf from non-release builds without (moving all the way towards using -O2 for debug builds), in my game engine I've reimplemented some stuff from libcore/liballoc, just with more aggressive
#[inline(always)] — this is... suboptimal obviously, and rather than continuing, it would be nice if we could just... do something about it)
¹ Other than the
#[inline(always)] one which, well, always runs.