There are unit tests in Polkadot and Kusama runtimes that fail if the core::mem::size_of<Call> is greater than 230 bytes. Kusama, Polkadot, Substrate.
What exactly is this size of and how was the limit chosen? More importantly is there any risk in it being too large? In our Joystream runtime the size of Call is reaching 350 Bytes.
The test does suggest using Box to reduce the size but its not clear how to do this.
Any advise would be appreciated.
There is no hard science here, the number selected is quite arbitrary.
Clippy explains why we would want to do this best:
What it does
Checks for large size differences between variants on enums.
Why is this bad?
Enum size is bounded by the largest variant. Having a large variant can penalize the memory layout of that enum.
Known problems
This lint obviously cannot take the distribution of variants in your running program into account. It is possible that the smaller variants make up less than 1% of all instances, in which case the overhead is negligible and the boxing is counter-productive. Always measure the change this lint suggests.
For types that implement Copy, the suggestion to Box a variant’s data would require removing the trait impl. The types can of course still be Clone, but that is worse ergonomically. Depending on the use case it may be possible to store the large data in an auxillary structure (e.g. Arena or ECS).
The lint will ignore generic types if the layout depends on the generics, even if the size difference will be large anyway.
I believe we specifically ran into memory allocation errors in the Wasm executor where we were WAY over-allocating memory for a Call, since some random variants were very large, and the memory allocator needs to handle the Call being those large variants.
~200 bytes was selected because clippy also warns at this size.
