Thank you for the good explanation and the article.
Are we confident that the increase in instruction count depends primarily on the GC? Or will the instruction count to, e.g., put an object in a TrieMap increase as the Trie grows?
Thank you for the good explanation and the article.
Are we confident that the increase in instruction count depends primarily on the GC? Or will the instruction count to, e.g., put an object in a TrieMap increase as the Trie grows?
We canât be confident until we measure
Thatâs what the theory predicts: if we ignore the GC costs, with the current implementation of TrieMap, the cost of inserting an object into a TrieMap should be almost independent of the map size: itâs proportional to the number of bits in the Hash, and the number of hash collisions in the bucket.
Ditto That will be for a future effort.
And the instruction count for the addition of an object to a List should be completely independent of the List size, correct?
Then it should, indeed, be the GC that dominates the increase in instruction count.
Itâs easy to verify. You can simply disable âforce GCâ and re-measure.
Can you force GC from dfx? Iâd like to measure that in our Rust/Motoko/Azle benchmarks that donât use the playground.
Sorry, must have missed your reply. The flame graphs are from Motoko Playground and the rest are made in LaTeX since I have been writing a paper about a messaging protocol on the IC.
Thereâs an interesting question on discord, and wanted to get the teamâs input on this:
Is it possible to track / log errors like âexceeding call limitâ or âout of cyclesâ. I guess that not on a canister level so not able to catch or am I wrong?
One scenario that I see here would be that the canister has to perform some large task. Letâs assume we want to perform a large task that can be split into sub-tasks based on a multiplier. It would be interesting if the canister itself can self-adjust that multiplier based on previous success. (e.g. batch convert 100 frames / request).
Thereâs a clear alternative where the multiplier gets sent by the requesting service, but it would be nice to know if this can somehow be detected by the canister itself.