ref-fvm
ref-fvm copied to clipboard
Wasm module compression
Currently, our actors are pretty large (over 2MiB in some cases). Unfortunately, we really want to keep a 2MiB upper limit on IPLD objects. If we don't fix this now, this will be a pain for us later as we start getting stricter about maximum IPLD block sizes in transports, blockstores, etc.
One solution here would be to compress them. This can easily bring our larger wasm modules down to ~700KiB.
using wasm-opt I am getting these result
# original
2.0M - fil_actor_account.wasm
# -O3 (speed aggressive)
1.6M - fil_actor_account-3.wasm
# -Os (size)
1.6M - fil_actor_account-s.wasm
# -Oz (size aggressive)
1.6M - fil_actor_account-z.wasm
Today for miner module:
serde_ipld_dagcbor::de::Deserializer<R>::recursion_checked monomorphization is 14% of the wasm module size: https://github.com/vmx/serde_ipld_dagcbor/blob/master/src/de.rs#L413-L424 this should be avoidable
serde_ipld_dagcbor::de::Deserializer<R>::parse_value is 20%.
@dignifiedquire:
- Make sure to strip (wasm-strip).
- Focus on the miner actor.
@Stebalien stripped miner actor (stripping done by rust profile, I couldn't get wasm-strip to work but should be the same) and then wasm-opt runs:
-rwxr-xr-x 1 kubuxu kubuxu 2719855 Apr 1 02:55 fil_actor_miner_original.wasm
-rw-r--r-- 1 kubuxu kubuxu 2182316 Apr 1 02:56 fil_actor_miner_O3.wasm
-rw-r--r-- 1 kubuxu kubuxu 2200479 Apr 1 02:57 fil_actor_miner_O4.wasm
-rw-r--r-- 1 kubuxu kubuxu 2146417 Apr 1 02:58 fil_actor_miner_Os.wasm
-rw-r--r-- 1 kubuxu kubuxu 2146304 Apr 1 03:00 fil_actor_miner_Oz.wasm
Yup. But with compression (zst), that goes down to 700kib, IIRC.
@Stebalien mind updating this with your latest discoveries re: compression?
For the miner actor (the largest):
- After upgrading to the new IPLD library and stripping, we're now down to 1.3MiB by default.
- If we optimize with
wasm-opt -O3 -Oz, we can get down to 1015KiB. - Compressed with zstd, we can get down to 288KiB.
So we can deploy the miner actor in around 5 messages if we use compression, or 16 messages if we don't.
We've stripped them as much as possible but likely won't compress them ourselves.
In M2.2, we expect users will come up with custom compression/chunking mechanisms.