Inline the layout-related methods as these basically change types and could benefit from cold branch removal.

[adamreichold]

No description provided.

[davidhewitt]

Sorry for the delayed review, this looks good to me 👍

I had stalled for a bit because these are generic functions and based off the discussion at PyO3/pyo3#2326 (comment) I wasn't sure if this achieves anything.

I just took a chance to play around with cargo rustc -- --emit=llvm-ir to look at what actually gets passed to llvm. It looks like the difference is that functions marked #[inline] carry the LLVM inlinehint attribute.

So my conclusion is that:

• Because generic functions are instantiated in the calling crate they might get inlined anyway.
• Adding #[inline] to generic functions can still have benefit because it provides an even stronger hint to LLVM to consider inlining.

Because they're generic functions this presumably also doesn't carry as much of a compile-time cost as marking a non-generic function #[inline]. The caller already has to codegen the concrete implementation, and the #[inline] attribute just adds a small hint to that codegen output.

So in summary, looks like there's definitely value in adding this.

cc @mejrs might be interesting to you too.

[adamreichold]

Because they're generic functions this presumably also doesn't carry as much of a compile-time cost as marking a non-generic function #[inline]. The caller already has to codegen the concrete implementation, and the #[inline] attribute just adds a small hint to that codegen output.

I would try to summarize things by "Generic function are available for cross-crate inlining independently of the inline attribute, but being generic by itself does increase the likelihood of being inlined."

In the end, this change here is probably not affecting things too much either way as LLVM's infamous heuristic for inlining seems to be "yes"...