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
There's mostly anecdotal data about the tradeoffs of different serialization techniques used by on-chain programs. The typically used ones are:
Pack by hand, as in token
unsafe pointer casts
Borsh, as in governance and stake-pool, among others
bytemuck, as in certain token-2022 extensions
bincode, not used in BPF programs, but builtin programs in the monorepo use it, such as stake
protobuf, a bit more overhead
any others?
Solution
Add in a new libraries/serialization style program that compares these different approaches. #3064 was the most bare-bones prototype possible that can be used for inspiration. Some features to compare them on would be:
compute unit usage for different structs / enum (for example, bincode is known to have high compute usage)
bloat of a compiled program (for example, borsh is known to make a compiled program huge)
ease of use (for example, bytemuck only allows for types that can be represented as bytes)
The text was updated successfully, but these errors were encountered:
Related issue: solana-labs/solana#23075. solana_prorgam unconditionally pulls in both borsh and bincode, so until that's fixed, all on chain programs that depend on solana_program will be somewhat bloated.
Problem
There's mostly anecdotal data about the tradeoffs of different serialization techniques used by on-chain programs. The typically used ones are:
Pack
by hand, as intoken
unsafe
pointer castsBorsh
, as ingovernance
andstake-pool
, among othersbytemuck
, as in certaintoken-2022
extensionsbincode
, not used in BPF programs, but builtin programs in the monorepo use it, such asstake
protobuf
, a bit more overheadSolution
Add in a new
libraries/serialization
style program that compares these different approaches. #3064 was the most bare-bones prototype possible that can be used for inspiration. Some features to compare them on would be:bincode
is known to have high compute usage)borsh
is known to make a compiled program huge)bytemuck
only allows for types that can be represented as bytes)The text was updated successfully, but these errors were encountered: