Ever-expanding storage using Actor Classes

Developers
1

So i just learned that we can create new canisters by using “Actor Classes”

  1. I want to create an ever expanding array that keeps on storing whatever I feed to it. And I have been thinking, is there a way to get how much % of heap memory and how much % of stable memory that my main/children canisters are consuming? I need to know these details so I can know when to stop accepting new data and begin creating new canister/actor class. For example, if the canister has utilized 99% of stable memory size (stable var arrays), and 99% of heap memory size (TrieMaps), then I would like to “let actorClass = await ActorClass.ActorClass()” and keep the principal id into my main indexer canister for lookups.

  2. How do I upgrade these created actor classes, if one day I would like to change the underlying design/datastructure of it?

  3. Is using Actor Class the best practice of creating new canisters? Or should I learn about using the IC Management canister (“aaaa-aa”)? If the latter, then where can I learn more about this? Is there an example for creating/installing/upgrading canisters by sending intercanister calls to IC management canister?

Thank you

2
  1. You can use rts_heap_size() to get used heap space
    When you are talking about (stable var arrays), you should understand that variables declared as stable are still stored in heap memory. They are moved in and out of stable memory on upgrades. You should only care about stable memory if you are using the ExperimentalStableMemory feature. In this case, as far as I know, the only way is to track allocated space yourself.
  2. You can upgrade subordinate canister from your main canister using
    await (system YourActorClass)(#upgrade(yourActor))(yourActorArgs);
    You can read more about this feature here Release 0.7.0 · dfinity/motoko · GitHub
  3. IC Management canister is handy when you have a wasm blob to create your canister with, actor classes - when you can import your code
1 Like
3

Hi @ZhenyaUsenko thanks for the informative reply.

  1. I see, then I will just use stable vars and TrieMaps then. Nice to know that there is rts_heap_size(). Is it a good idea to always check if the heap is about to hit 4GB? since that is the heap size limit right now if I’m not mistaken. Or should I check the limit with ICManagement.canister_status() -> ..., memory_allocation: Nat, ...?
  2. Thanks for this!
  3. If I’m reading Install Code via IC Management doc correctly, I will need to use moc (Motoko Compiler) to generate the wasm_module parameter yes?
4

You will have better luck with performance if you use GitHub - ZhenyaUsenko/motoko-hash-map: Stable hash maps for Motoko

1 Like