Performance features and #[inline]

[pinkforest]

Reviving this thread as a separate feasibility discussion around at least:

Question 1: Should we do performance selection via features ?

This would include perhaps providing features to maybe enable something like this this -

• Separating backends into their own crates? #287 (comment)

Question 2: If we provide these features would that provide confidence to impl. crate separation for backends ?

Question 3: Is the tradeoff more around compile time for crate separation and is it relevant today ?

Some people put these things behind a feature flag e.g. regex pointed out by BurntSushi:
https://docs.rs/regex/latest/regex/index.html#performance-features

There was some concern around LTO / cross-crate inlining I think around late 2019 and this may alleviate those ?

Also there is now some LTO changes in 1.65:
https://www.reddit.com/r/rust/comments/ycmqml/the_rust_compiler_is_now_compiled_with_thin_lto/
And some other changes.

There was extensive chatter around #[inline] and how it works today - or a year ago?:

• Remove most #[inline] annotations rust-lang/hashbrown#119

BurntSushi also pointed out a potential downside to these features - which are around build time:

• "If we would not add any performance features like in regex which would have a side effect - "
• "Of course, if you depend on anything that depends on hashbrown that enables the feature, then I don't think it can be turned off."

Other than doing some feature driven [cfg_attr()] - would either generic functions work as an alternative ?

Also are Rust inline docs today accurate -

There is also bunch of #[inline] discussion how it works supposedly today vs docs: rust-lang/hashbrown#119 (comment)

Fromn alexchrichton how #[inline] works today:

"In release mode the compiler will, by default, codegen an #[inline] function into every single referencing codegen unit , and then it will also add inlinehint . This means that if you have 16 CGUs and they all reference a hash map, every single one is getting the entire hash map implementation inlined into it."

Further from alexchrichton:
https://users.rust-lang.org/t/enable-cross-crate-inlining-without-suggesting-inlining/55004/9

1. "Currently #[inline] codegens it into all referencing codegen units."
2. "For the first option we have 3 options - don't codegen into downstream crates, codegen into one CGU of any referencing downstream crate, or codegen into all CGUs. For the second we have 2 options, either apply the attribute or not."

[tarcieri]

Adding or removing #[inline] should hopefully be measurement-driven. It really does benefit codegen frequently (the last time I saw such benefits was earlier today, as it were).

It would be good to measure and document the impact of #[inline] directives, and if they're being removed, carefully measure how that impacts performance.