Wasm module contains a function that is too complex

Developers
41

I hope we release 0.12.0-beta.4 soon as we had a bug in dfx generate. I’m trying to get the complexity limit into that as well.

1 Like
42

I just tried out dfx 0.12.0-beta.4 and it looks like the complexity limit is included. I’ve been able to switch over to ic-wasm from ic-cdk-optimizer. I’m still using a modified version of RustPython, which had the original limit on the number of functions. I will eventually try to get back to the upstream version of RustPython and then hopefully this entire problem for me has been resolved.

Thanks for all of the work you’ve been putting in.

43

Update: I still can’t use ic-wasm, as the optimization in Wasm binary size is not as good as ic-cdk-optimizer.

For a simple Kybra (Python) canister that I’m using to test with:

When using ic-cdk-optimizer, my original Wasm binary is 9.8MiB, which is then optimized to 5.4MiB, which is then gzipped to 1.8MiB, which can be successfully deployed.

When using ic-wasm shrink, my original Wasm binary is 9.8MiB, which is then optimized to 8.7MiB, which is then gzipped to 2.2MiB, which cannot be successfully deployed.

Is there something I’m missing in my usage of ic-wasm?

44

ic-wasm shrink only performs dead code elimination, so it’s expected that wasm-opt/ic-cdk-optimizer can shrink the wasm size much further. The only problem with wasm-opt is that it also removes the canister metadata from wasm module, and there doesn’t seem to have an easy way to disable it. Well, we could store the metadata before wasm-opt and then save them back after the optimization…

2 Likes
45

I just wanted to confirm that the Wasm module contains a function that is too complex issue has been resolved for us as of dfx 0.12.0. All of our Kybra tests are passing without the hack we had to do in RustPython to get around this issue.

3 Likes