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.
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-optimizerwas built on top ofbinaryencrate 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-wasmis built on top ofwalruscrate which is native Rust. It enablesic-wasmnot 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.
I’ve shared it with abk, if you’d like it directly from me can we chat on Discord or Telegram?
In regards to the original request, it looks like we can lift this limit enough for the optimized RustPython code to work.
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
Latest beta is available. Install command:
DFX_VERSION=0.12.0-beta.3 sh -ci "$(curl -fsSL https://smartcontracts.org/install.sh)"
ic-wasm never worked for me : the “shrinked” output is the same size as the original one.
I wonder what I am missing here ![]()
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.
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
So the complexity limit should soon be 15_000 and the function limit should soon be 50_000? @Vivienne 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.