Research reducing monomorphization bloat by delegating to non-generic implementations

[cmichi]

These two blog posts describe techniques for reducing monomorphization bloat by having only a thin generic interface layer, which immediately delegates to a non-generic implementation:

https://llogiq.github.io/2019/05/18/momo.html

https://matklad.github.io/2021/09/04/fast-rust-builds.html

The Hackernews comments also contain some good ideas: https://news.ycombinator.com/item?id=28425095.

There is also the momo crate, which implements a macro for this technique.

We should look into if this is applicable to ink!.

[Robbepop]

We might also find a lot of use for this technique in heavily used derive dependencies such as parity-scale-codec.

[cmichi]

We might also find a lot of use for this technique in heavily used derive dependencies such as parity-scale-codec.

That's a good point. And also a reminder of why the compiler team efforts are necessary despite any of the changes we will make to ink! (i.e. third party crates which have monomorphization bloat).

[ascjones]

I always wondered what that fn inner was about! TIL

[xgreenx]

What do you think about rewriting the parity-scale-codec and some traits/logic(SpreadLayout, StorageLayout and etc) in the ink! to use dynamic dispatching instead of monomorphization?

I think that the combination of #916 really will reduce the size of the contract.

BTW, adding the getter/setter/method to the contract adds ~0.3kb, maybe we also can try to reduce code-generation for call.

[Robbepop]

Dynamic dispatch is not always the cure but also brings plenty of problems with it sometimes.
For example it is much harder for the compiler to optimize across function boundaries and therefore sometimes dynamic calls can even lead to more produced binary code in the worst case.
In ink! we profited a lot by producing code that can be heavily optimized by the compiler which can be observed by the fact that very small and contained smart contracts are compiled down to roughly 1kB which is close to optimal.
I am sure that with some other adjustments following the removal of state rent and some other techniques to tear down some monomorphisation bloat without reducing optimization potential we can gain a lot of ground for more complex smart contracts.

We see the biggest bloat in the ink_storage facilities due to the fact that they have been written for automatic removal of contract storage which no longer is a declared goal with removal of state rent. Also caching sometimes hurts the performance instead of helping it. We will push forward by rewriting some of our ink_storage facilities and simplify them as well as introducing new ones with even less overhead similar to the ones provided by Solidity.

[athei]

Just linking #873 (comment) for reference. This is a method to check for monomorphization bloat. Maybe we can even add convenience command to cargo contract?