NFTAnvil IC network tests report

[icme]

@justmythoughts

Any input on why the Motoko HashMap library takes up 28X memory vs. TrieMap? I would expect it to take up maybe 2-3X (Hash Table Array doubling & collision lists), but this seems like a pretty unexpected result, suggesting that either the HashMap implementation or mutable Arrays (the underlying hash table) take up more memory than expected.

Tagging Motoko to hopefully get some additional eyes on this.

I’m also very curious about this large memory discrepancy between HashMap and TrieMap.

@claudio do you have any ideas regarding why the memory usage is so much higher for HashMap? And were there any benchmarks run on the modules in motoko-base beforehand that can be referenced?

Based on the table resizing code link @justmythoughts posted, the load factor for the current HashMap implementation is 1 (hash table waits until count >= size of the array to double. I could see memory usage being 4X or 10X if the load factor was 0.25 or 0.1 respectively, but it makes no sense that the memory usage is 28X that of TrieMap with a load factor of 1.

I wonder if it hash anything to do with this issue, and not necessarily that the HashMap is less space efficient

Motoko canister memory size increased after upgrade

This is not unexpected: For the upgrade, the Motoko runtime serializes your whole state to stable memory, in a format that is almost like Candid. This is not implemented in the most efficient way yet; in particular it will increase the main memory to have space to assemble the candid data. serialized the data in Candid format into that space copy it in bulk to stable memory (now the upgrade happens) increase the main memory to have space for the encoded candid data copy it in bulk from the sta…