The stellar-cli embeds the wasm-opt tool and will run it on contracts after build to optimize them.
When we added the tool it was assumed maybe we need it, maybe it would be valuable. However in a lot of the past tests I did, Soroban contracts were already very well optimised because they don't pull in cruft from the Rust stdlib, which in early testing was where the biggest bloat arose from.
To my knowledge we've never done an assessment of real contracts to see if the size gains are actually meaningful. If the gains are not meaningful I will propose we remove the feature to reduce the surface area of what touches binaries between code and the wasm that runs on chain.
cc @brson
The stellar-cli embeds the wasm-opt tool and will run it on contracts after build to optimize them.
When we added the tool it was assumed maybe we need it, maybe it would be valuable. However in a lot of the past tests I did, Soroban contracts were already very well optimised because they don't pull in cruft from the Rust stdlib, which in early testing was where the biggest bloat arose from.
To my knowledge we've never done an assessment of real contracts to see if the size gains are actually meaningful. If the gains are not meaningful I will propose we remove the feature to reduce the surface area of what touches binaries between code and the wasm that runs on chain.
cc @brson