Experiencing this issue with a test project on 0.7.0-beta.3 version of DFX. This works fine with 0.7.0-beta.2.
Note: there are no where near 6000 functions defined in this project.
I’ve uploaded a project that reproduces the issue here.
Experiencing this issue with a test project on 0.7.0-beta.3 version of DFX. This works fine with 0.7.0-beta.2.
Note: there are no where near 6000 functions defined in this project.
I’ve uploaded a project that reproduces the issue here.
Thanks @shan I’ve flagged this internally; will follow up.
Hi @shan, we’ve added checks recently to avoid unnecessarily large wasm modules.
I see in your Dorsfile.toml
that you are building your project in debug
mode:
command = '''
cargo build --target wasm32-unknown-unknown --package $@ &&
ic-cdk-optimizer ./target/wasm32-unknown-unknown/debug/$@.wasm -o ./target/wasm32-unknown-unknown/debug/$@_opt.wasm
'''
I recommend compiling your project in release
mode instead for a more efficient wasm. Try this instead:
command = '''
cargo build --target wasm32-unknown-unknown --release --package $@ &&
ic-cdk-optimizer ./target/wasm32-unknown-unknown/release/$@.wasm -o ./target/wasm32-unknown-unknown/release/$@_opt.wasm
'''
Thanks; I built with --release
earlier and still was encountering the error so figured it was a bug, but think I forgot to switch my wasm module definition in the build script to the release output. Is there any way to query for the number of functions defined in the wasm module besides decompiling it with something like wabt’s wasm-decompile
and just inspecting it manually? Maybe with a build arg for the ic_cdk_optimizer
?
If you’ve got the wabt
tools lying around anyway you can use wasm-objdump
:
~\code\purescript-wasm [main ≡ +0 ~3 -0 !]> wasm-objdump.exe -h .\bytes.wasm
bytes.wasm: file format wasm 0x1
Sections:
Type start=0x0000000e end=0x0000001e (size=0x00000010) count: 3
Function start=0x00000024 end=0x00000028 (size=0x00000004) count: 3
Export start=0x0000002e end=0x00000036 (size=0x00000008) count: 1
Code start=0x0000003c end=0x00000076 (size=0x0000003a) count: 3
Perfect, exactly what I was looking for. Thank you!
@shan
Do not forget change dfx.json
{
...
"canisters": {
"your_canister": {
...
"wasm": "./target/wasm32-unknown-unknown/release/your_canister_opt.wasm",
}
},
...
}
I just ran into this issue.
What’s strange is that if my top-level Cargo.toml
looks like this:
[workspace]
members = [
"canisters/boa",
]
[profile.release]
lto = true
opt-level = 'z'
then I get the error. But if I add codegen-units = 1
then the error goes away:
[workspace]
members = [
"canisters/boa",
]
[profile.release]
lto = true
opt-level = 'z'
codegen-units = 1
And this is without using ic-cdk-optimizer
.
Have you checked the top part of your WAT?
https://webassembly.github.io/wabt/demo/wasm2wat/
Im curious if there is anything interesting there. But you should see every import/export there.
Hi, bumping this. We’re actually completely at a standstill now with our project because we’ve hit the 6000 function limit. Is there anybody we can talk about about raising it?
It’s not a design issue, we have a lot of code and make heavy use of anonymous functions. There are 2396 functions defined in the codebase (excluding base libraries), and wasm is telling us there are 6088.