Used to work fine till v0.11.2
Thoughts?
Running into the same thing after upgrading.
What canister type are you using? There shouldn’t have been any changes that make wasms larger… Unlikely, but are you using "shrink" : false,
in your dfx.json?
Not using "shrink": false
.
Here’s a screenshot of running the exact same install script now downgraded to v0.11.2
Works fine and completes installing canisters
Can also confirm that shrink ran when running the install script on dfx v0.12. Here’s a screenshot:
Didn’t set any canister type specifically.
Here’s the steps that I did:
dfx upgrade
rm -rf
the .dfx
and target
folders in my project directory"networks"
entry from dfx.json
dfx start
and successfully started replicaThanks for the details. Since you mention the target
folder: Is it a Rust project?
Yes, it’s a rust project
Have you inspected the canister wasm modules before and after dfx
upgrade?
Did dfx v0.11.2
produce much smaller wasm than dfx v0.12.0
?
I just checked.
Here’s with dfx v0.11.2
Here’s with dfx v0.12.0
This is in the /target/wasm32-unknown-unknown/release
folder
In short, for wasm size optimization, dfx v0.11
ran ic-cdk-optimzer
while dfx v0.12
ran ic-wasm shrink
. The later one currently could not produce the same optimization as before.
This is a known limitation of ic-wasm shrink
. We want to improve it to unblock more use cases like yours.
For a short-term workaround, could you either keep using dfx v0.11
or change your canister to custom
type and run ic-cdk-optimizer
in build script?
Yes, we have currently downgraded to v0.11.2.
But eagerly waiting to upgrade to v0.12 to try out the juicy new things like dfx nns
and all
Any updates on this?
We have just started running into the wasm size limitation on dfx v0.11.2 as well, as our canisters grow further.
Are there any plans to enable canisters larger than 2MB to be uploaded on the IC?
Looks like we are currently 1kb over the size limit
We have the same issue, unfortunately the only thing I can recommend for now is to gzip your wasm before uploading. it reduces the wasm size 2-5/3 times in size.
This works on dfx v0.11.x as well?
if your question is to gzip, then yes
Thank you for the inputs @Gabriel
What do the steps look like on your end?
My build steps look like this
dfx canister create --no-wallet backend_canister
dfx build backend_canister
dfx canister install backend_canister
dfx generate backend_canister
There are steps in between but this is the simplified version.
And my dfx.json has an entry like this:
"backend_canister": {
"type": "rust",
"package": "backend_canister",
"candid": "./canister/backend_canister/can.did",
"declarations": {
"output": "./web-client/declarations/backend_canister"
}
}
Any changes required here?
Appreciate the inputs
Hey, sorry for the late answer
You can use this dfx deploy with gzip · Issue #2357 · dfinity/sdk · GitHub
I don’t have a full example yet but working on it, I’ll share as soon as possible.
No worries, I figured it out. It’s quite straightforward.
For future readers, the way to do it is to run gzip right after the build step. DFX picks it up automatically. Like this:
dfx build <canister_name>
gzip -f -1 ./target/wasm32-unknown-unknown/release/<canister_name>.wasm
oh, that’s a neat way, but I would rather have dfx automatically gzip instead of running an extra command that I might forget about it hah.
Also, did gzip fixed your issue?
Yeah, they are significantly smaller now. I was even able to upgrade to dfx v0.12 due to this. These are my wasm sizes now