Wasm module contains a function that is too complex

We want ic-wasm to be a full replacement for ic-cdk-optimizer so this is an issue. I’ll ping the relevant folks for that.

3 Likes

Hi @lastmjs,
We are deprecating ic-cdk-optimizer. And ic-wasm shrink is the replacement for reducing canister size.
That is not a 1:1 replacement. For some particular cases, people may have to still use ic-cdk-optimizer. It seems that currently ic-wasm shrink doesn’t work for your case.

Let me explain a bit about why we want to make this tool migration.

  • ic-cdk-optimizer was built on top of binaryen crate which is an incomplete wrapper over the C library. The dependency crate is not actively maintained and it’s hard to tune it for our usage for IC.
  • ic-wasm is built on top of walrus crate which is native Rust. It enables ic-wasm not only to reduce WASM size, but also do more kinds of WASM module surgery. We envision it to be a versatile tool to process IC Canister WASM.

We will keep working on ic-wasm so that it can satisfy more and more use cases. Could you share your WASM module? So that we can start investigating if we can make ic-wasm shrink work for you.

3 Likes

I’ve shared it with abk, if you’d like it directly from me can we chat on Discord or Telegram?

No worries @lastmjs. I can pass it on to @lwshang.

In regards to the original request, it looks like we can lift this limit enough for the optimized RustPython code to work.

2 Likes

That would be fantastic

I just tried it and it doesn’t appear to have been changed from 10,000.

You’re right, I believe it was the difference between ic-wasm and ic-cdk-optimizer that obscured the bug. I was trying a lot of different things.

@abk do you know when we might see a version of dfx that reflects the increased limit?

We would like to cut a (likely beta) release this week, but we have a couple blockers to clear before that

3 Likes

Latest beta is available. Install command:

DFX_VERSION=0.12.0-beta.3 sh -ci "$(curl -fsSL https://smartcontracts.org/install.sh)"
2 Likes

ic-wasm never worked for me : the “shrinked” output is the same size as the original one.
I wonder what I am missing here :thinking:

Here is the command I am using :

ic-wasm main.wasm -o main.ic-wam.wasm shrink

wasm-opt is working fine though.

I just tried switching to dfx 0.12.0-beta.3 and from ic-cdk-optimizer to ic-wasm for Kybra, and whereas in ic-cdk-optimizer everything is working, I now get:

Installing canisters...
Creating UI canister on the local network.
The UI canister on the "local" network is "ryjl3-tyaaa-aaaaa-aaaba-cai"
Installing code for canister query, with canister ID rrkah-fqaaa-aaaaa-aaaaq-cai
Error: Failed while trying to deploy canisters.
Caused by: Failed while trying to deploy canisters.
  Failed while trying to install all canisters.
    Failed to install wasm module to canister 'query'.
      Failed to install wasm in canister 'rrkah-fqaaa-aaaaa-aaaaq-cai'.
        Failed to install wasm.
          The Replica returned an error: code 5, message: "Wasm module of canister rrkah-fqaaa-aaaaa-aaaaq-cai is not valid: Wasm module contains a function at index 0 with complexity 10116 which exceeds the maximum complexity allowed 10000"

Is it worth creating environment variables for these function and complexity limit values so that anyone running into them for the first time isn’t immediately blocked on local development?

That’s really weird I thought beta.3 contains the change already. @abk can you point me to the commit, please?

And @lastmjs unlikely, but possible problem: did you change the dfx version in dfx.json as well? It could have started the old version if you specify an older version.

I didn’t specify a version in the dfx.json, I never do usually so I’m pretty sure it was the right version. Also notice that the error was for complexity this time and not for the number of functions, not sure if that makes a difference. What was the complexity limit raised to?

Here’s the commit: RUN-344: Raise complexity limit · dfinity/ic@ac4ed94 · GitHub

The limit was increased by 50% to 15,000.

1 Like

Looks like the limit increase was committed not quite half a day after the latest replica update… Will be included with the next replica update for sure

1 Like

So the complexity limit should soon be 15_000 and the function limit should soon be 50_000? @severin do we know yet what version of dfx these changes will be in? I’m running into these limits again locally.

Okay it looks like dfx 0.12.0-beta.3 has the function limit increase from what I can tell. Just waiting on complexty I suppose, I am unblocked for now though which is nice.