I have an issue where I have a few actor classes that I want to deploy from my main canister but I am running into an issue where each actor class takes about ~500KB of WASM space, so im looking into alternative options. Here is what I see as options
Spread out the actor classes to other canister(s)
Deploy actor classes from dfx (This might have an issue of not being deployable via a DAO)
Call the factory and have it create the canister, add your main canister as a controller and hand you back the principal.
This will be a tad slower, but your main canister will only need references to Interfaces for your canisters instead of having all the canister/system code in binary repeated over and over.
I originally developed it because my test Actors would blow up to a huge size when trying to test complicated scenarios. It works great for that and I would imagine it working well in production, especially for something like you’re building where you’re going to have a bunch of different kinds of canisters all working together.
@skilesare do you have any tips for how to cleanly give a factory canister the main canister principal?
I always seem to have a cyclical reference issue with Main ↔ Other Actor. I dont like hard coding the value, which works, but isnt great. Also I have thought of the idea of having to initializing it post deploy, but that isnt perfect either.
When you say factory actor are you referring to using the IC Mangement canister and creating a canister with provisional_create_canister_with_cycles? Then using the install_code function to load wasm into the newly created canister?
Also if a canister were to create a new canister using the traditional method as defined in:
The newly created canister is completely seperate from the main canister that created it right? Its not like the main canister that created it is storing the code for every single new canister it creates. It just stores one implementation of the source code that is needed to create the new canister. Right?
You are generally correct. When a motoko canister references another actor class it puts that subactor wasm in the the canister code(you can see this if you decompile the wasm). I dont’ think it is smart enough to not copy repeated code like the base libraries so it blows up a bit. I have some stuff in the pipeline for a more streamlined, open, transparent, and trackable process, but need some time to build it out.
So are you saying that when an actor class is instantiated within a parent canister that the parent canister does in fact hold all of the code and data for every child actor class that it instantiates? Adnt that due to this the parent canister can become overloaded if a lot of child actor classes are created?
If so, could you please further explain what you mean by factory actor. Im not sure I fully understand how that is supposed to work. Thanks.
Not quite…yes it has the code for all children, but all children are the same so it has one copy of the code and all children share that code(It can of course have more than one kind of child, but it would have one set of code for each type of child).