Indeed, I think it might be useful to embark on a project to review *all* the uses of #[inline(always)] that currently exist and determine their necessity. I too have been guilty of using it where #[inline] alone would suffice.
On Wed, May 29, 2013 at 11:15 PM, James Miller <[email protected]> wrote: > Hello Everyone, > > I've been doing work around optimizations recently, and noticed that > libextra was taking an > inordinate amount of time to build. My investigations led me to find that > well over half the time > spent was on Loop Invariant Code motion, i.e. moving expressions that > don't change out of the loop. > > One of the more common cases turns this: > > while i < n { > data.field[i] = something(i); > i += 1; > } > > into this: > > let tmp = data.field; > while i < n { > tmp[i] = something(i); > } > > since, the field access is invariant. > > Anyway, the BigInt module uses this pattern a lot. It also has 112 > functions marked with > #[inline(always)]. This does two things: causes massive code bloat, 2 > orders of magnitude worth of > code bloat, and makes later passes work much, much harder. Many of the > functions in BigInt would > have been inlined multiple times into one function, and in some cases, > those functions would be > further inlined into other functions, despite blowing past the normal > inline cost limit. > > This meant that a fairly simple, standard pass, was being called on over > 100x more code than it > needed to be. If you want to know why a full build takes so long, there is > why. > > Inlining is a pretty standard optimization, and is potentially done for > every function that isn't > marked with `#[inline(never)]`, but the compiler is smart enough to know > when it's not worth it. > `#[inline(always)]` is a very strong statement, and should be reserved for > cases where you are > certain that the function absolutely needs to be inlined, no exceptions. > Remember that "always" > means it, so every single function that uses it will get a copy. > > Inlining is not a magic bullet for performance and the compiler passes are > far smarter at knowing > what is more efficient than you are. > > Thank you for your time, > James Miller > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
