mandrean / cw-optimizoor

A blazingly fast compiling & optimization tool for CosmWasm smart contracts.
MIT License
50 stars 6 forks source link

Produces larger binaries than cosmwasm workspace-optimizer #20

Open de-husk opened 2 years ago

de-husk commented 2 years ago

I noticed that the cw-optimizoor optimized binaries are a bit larger than the rust workspace-optimizer for the DAO DAO contracts.

cw-optimizoor:

$ ls -lh artifacts | grep wasm | awk '{print $5,$9}'
293K cw20_stake-x86_64.wasm
295K cw20_staked_balance_voting-x86_64.wasm
196K cw4_voting-x86_64.wasm
278K cw721_stake-x86_64.wasm
161K cw_admin_factory-x86_64.wasm
404K cw_core-x86_64.wasm
175K cw_named_groups-x86_64.wasm
209K cw_names_registry-x86_64.wasm
219K cw_native_staked_balance_voting-x86_64.wasm
495K cw_proposal_multiple-x86_64.wasm
501K cw_proposal_single-x86_64.wasm
178K cw_token_swap-x86_64.wasm
244K stake_cw20_external_rewards-x86_64.wasm
190K stake_cw20_reward_distributor-x86_64.wasm

cosmwasm workspace optimizer:

$ ls -lh artifacts | grep wasm | awk '{print $5,$9}'
257K cw20_stake.wasm
261K cw20_staked_balance_voting.wasm
193K cw4_voting.wasm
276K cw721_stake.wasm
143K cw_admin_factory.wasm
407K cw_core.wasm
173K cw_named_groups.wasm
188K cw_names_registry.wasm
216K cw_native_staked_balance_voting.wasm
455K cw_proposal_multiple.wasm
460K cw_proposal_single.wasm
171K cw_token_swap.wasm
226K stake_cw20_external_rewards.wasm
171K stake_cw20_reward_distributor.wasm

You can see the % difference here: https://github.com/DA0-DA0/dao-contracts/pull/474#issuecomment-1234664958

I wonder if there is a different optimization flag being used?

mandrean commented 2 years ago

It does use the same optimizations: https://github.com/mandrean/cw-optimizoor/blob/master/src/optimization.rs#L72-L74

I wonder if it could be related to the issue with unified feature flags across workspace members in a monorepo maybe.

Let's say cw20_stake depends on some library_a with feature flag x while cw4_voting relies on library_a with feature flag y

Then according to Cargo's built-in feature-flag resolver, it will build library_a for both cw20_stake and cw4_voting with both flag x and y enabled. Worth looking into

de-husk commented 2 years ago

Makes sense that the issue is likely related to some of the contracts being used by other contracts with the library feature.

Just to test, I ran the latest cw-optimizoor against the DAO DAO contracts, but compiling everything 'normally', commenting out the compile_ephemerally() step.

Ignoring the empty wasms, the contracts look to be about the same size as workspace optimizer:

ls -lh artifacts | grep wasm | awk '{print $5,$9}'
13K cw20_stake-x86_64.wasm
265K cw20_staked_balance_voting-x86_64.wasm
196K cw4_voting-x86_64.wasm
278K cw721_stake-x86_64.wasm
143K cw_admin_factory-x86_64.wasm
13K cw_core-x86_64.wasm
175K cw_named_groups-x86_64.wasm
194K cw_names_registry-x86_64.wasm
219K cw_native_staked_balance_voting-x86_64.wasm
452K cw_proposal_multiple-x86_64.wasm
456K cw_proposal_single-x86_64.wasm
158K cw_staking_denom_voting-x86_64.wasm
178K cw_token_swap-x86_64.wasm
229K stake_cw20_external_rewards-x86_64.wasm
175K stake_cw20_reward_distributor-x86_64.wasm

Not sure how the cosmwasm rust workspace optimizer gets around this issue.

Also Im realizing now that I made an issue "wasms too small" and now a "wasms too big" issue lol, sorry.