It is the same repo as last week. I’ll dm the branch.
You can just build one item in dfx and then inspect the wasm.
@ZhenyaUsenko Tried replacing some of the actor references with interface references that had imports and the file got BIGGER. Then he ran the distilled candid through the did → motoko to get rid of the imports and it got bigger again.
We are getting close to the limit of where we’ll be able to deploy. It would be good to find the culprit so we can engineer for it.
I’m thinking we may need to end up having “factory” canistors that only reference one actor and are asked to deploy and transfer control to our management canisters so that it doesn’t have to reference the actors directly. This would be unnecessary complexity but may become necessary unless we can identify an optimization.
I was thinking of suggesting that solution too, but now that I’ve managed to build your project and look at the wasm, I’m beginning to wonder if we don’t actually have a bug in the code generator.
Your code seems to import 6 or so actor classes, non-recursively as far as I can tell, and that doesn’t seem to match the number of meta-data sections I’m seeing in the binary. So I’m wondering if we are indeed duplicating string constants, perhaps by forgetting to purge the constant pool when we do a recursive build of an actor class.
I suspect the compiler is linearizing the dependencies between libraries for the entire project, but when it compiles an imported actor class, it’s including all the (preceding) libraries in the global order, not just this class’s actual dependencies, leading to duplication of code.
So when you import a sequence of actor classes, each class will import all of the preceeding ones, not just the ones it actually needs.
This is pretty bad, but won’t be a super-quick fix.
@nomeata does that seem like a reasonable diagnosis?