Add optimize sub-command using wasm-opt

[leighmcculloch]

What

Add optimize sub-command using wasm-opt.

Why

I saw @brson and @Aimeedeer's blog post about the wasm-opt crate today and after a quick test it appears to work very smoothly. Including optimization into the soroban-cli rather than instructing people to install other tools seems like it fits our philosophy of making writing effecient contracts the default.

This PR introduces an ultra simple sub-command (soroban optimize) that runs wasm-opt across the given .wasm file with the -Oz mode, which is the same mode we currently recommend.

I imagine we might also want to automatically run this across .wasm files as part of the deploy subcommand, although I thought doing that at this time, given that we are considering redesigning the CLI (#197), might be a bit premature.

[leighmcculloch]

I have a concern about merging this:

• The wasm-opt crate requires a C compiler to also be installed. That might mean that cargo installing this crate might not work in all the cases that it works today. It is unlikely to be a big problem, but I'm not sure.

I am not attached to merging / adding this if folks think it isn't a good idea.

[leighmcculloch]

❯ soroban optimize --wasm target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm
Reading: target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm (4414 bytes)
Writing to: target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm...
Optimized: target/wasm32-unknown-unknown/release/soroban_auth_contract.wasm (3522 bytes)

[dtolnay]

• The wasm-opt crate requires a C compiler to also be installed. That might mean that cargo installing this crate might not work in all the cases that it works today. It is unlikely to be a big problem, but I'm not sure.

You already depend on ring (via rustls, via jsonrpsee-http-client) which uses a C compiler.

[brson]

I have published version 0.110.2 of this crate that contains a single Binaryen backport that slightly reduces output size when the input module contains no "memories" section.

[leighmcculloch]

I have published version 0.110.2 of this crate that contains a single Binaryen backport that slightly reduces output size when the input module contains no "memories" section.

Ah nice.

@brson Thank you!

[paulbellamy]

Initially, I'm a bit on the fence about this.

Argument for including the soroban optimize command:

• It is a generic wasm command which is applicable regardless of contract SDK used.
• We may wish to integrate it into the deploy process automatically
• We already have soroban inspect which is a wasm-specific command
• Batteries-included approach to efficient contract development

Argument for excluding the soroban optimize command:

• It is a build-step process, which should be dealt with as part of the build pipeline (rust/make/npm/whatever).
• soroban-cli should not modify the wasm it is receiving (e.g. optimizing in deploy)
• Reinforces the C compiler dependency
• Automatically optimizing as part of deployment could make repeatable builds and source-code verification harder? (are repeated wasm-opt calls idempotent?)

But, overall, from writing that down, I think this SGTM.

[leighmcculloch]

• It is a build-step process, which should be dealt with as part of the build pipeline (rust/make/npm/whatever).

For npm projects this makes sense. For Rust projects, there's no way to hook post-build steps into a project.

The reason to include wasm-opt into soroban isn't to take over the build pipeline (although #226 is probably getting into that territory), but to provide easy access to wasm-opt. Wasm-opt can be installed in a variety of ways that complicate system setup. Since devs already need to have soroban installed, we can say here's this default set of tools that is builtin that you can use to optimize.

But maybe it is being too opinionated.

• Automatically optimizing as part of deployment could make repeatable builds and source-code verification harder? (are repeated wasm-opt calls idempotent?)

Good point. Your comment also got me thinking that automatically modifying contracts during deploy could be surprising, and if there was ever a bug there's no opportunity for a developer to test out the artifact before it deploys.

[leighmcculloch]

• are repeated wasm-opt calls idempotent?

I did some tests with this and it appears no. I managed to get a .wasm file even smaller by running it multiple times.

[willemneal]

@leighmcculloch there is a --converge option on the CLI which should result in the same binary as manually rerunning it until it stops decreasing.

[leighmcculloch]

Thanks @willemneal. I'm experimenting with that option in #238.