You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Borsh and bincode, the serialization libraries used by the solana-program crate and many solana programs, bloat significantly the .text section of compiled SBF programs. Bincode is especially bad since it pulls in serde, which notoriously generates a lot of code.
Proposed Solution
Ideally we should put APIs that use borsh and serde behind rust features, so that consumers of the solana-program crate would have a way to opt out of either (or both).
Doing this for bincode (and therefore serde) might be nearly impossible tho considering how pervasively it is used everywhere (eg sysvars and system instructions). Until we switch the core stuff away from bincode, a more realistic short term approach could be building something like https://docs.rs/miniserde/latest/miniserde for bincode.
As for borsh, I've fixed an issue in near/borsh-rs#77 and have been looking at another possible workaround, see near/borsh-rs#81. My hacked up version of BorshDynSerialize reduces the size of solana-program-library significantly. We could try switching to dynamic dispatch in solana-program and anchor too (anchor uses borsh by default and seems to generate a lot of boilerplate).
Part of the reason why these libraries generate a lot of code is that they make heavy use of generics and interact badly with the rust monomorphizer. We could try enabling rust-lang/rust#48779 by default for SBF to try and reduce monomorphized duplicates. I have in fact tried this, and it makes a big impact for SPL, but it also causes regressions for other programs I've tried, so there's $some work to do there.
The text was updated successfully, but these errors were encountered:
Problem
Borsh and bincode, the serialization libraries used by the
solana-program
crate and many solana programs, bloat significantly the.text
section of compiled SBF programs. Bincode is especially bad since it pulls in serde, which notoriously generates a lot of code.Proposed Solution
Ideally we should put APIs that use borsh and serde behind rust features, so that consumers of the
solana-program
crate would have a way to opt out of either (or both).Doing this for bincode (and therefore serde) might be nearly impossible tho considering how pervasively it is used everywhere (eg sysvars and system instructions). Until we switch the core stuff away from bincode, a more realistic short term approach could be building something like https://docs.rs/miniserde/latest/miniserde for bincode.
As for borsh, I've fixed an issue in near/borsh-rs#77 and have been looking at another possible workaround, see near/borsh-rs#81. My hacked up version of
BorshDynSerialize
reduces the size ofsolana-program-library
significantly. We could try switching to dynamic dispatch insolana-program
and anchor too (anchor uses borsh by default and seems to generate a lot of boilerplate).Part of the reason why these libraries generate a lot of code is that they make heavy use of generics and interact badly with the rust monomorphizer. We could try enabling rust-lang/rust#48779 by default for SBF to try and reduce monomorphized duplicates. I have in fact tried this, and it makes a big impact for SPL, but it also causes regressions for other programs I've tried, so there's $some work to do there.
The text was updated successfully, but these errors were encountered: