I might have already asked, so please accept my apologies for the duplicate if that’s the case.
Is there a specific reason why stable-structures is limited to 256 MemoryId? If, for example, one would like to use, let’s say, 65,535 different memories, would that be possible?
There’s a non-negligible memory overhead associated with the creation of every new VirtualMemory. The choice of limiting # memories to 255 is to discourage design patterns that require allocating so many memories, as they would be inefficient. Do you have a specific use-case in mind?
In Juno, developers can create as many “collections” as they want, both in heap or stable memory, to save their data. Currently, if they opt for stable memory, there is one unique StableTreeMap that contains every entry, with the collection used as part of the key. However, this doesn’t feel very performant, which is why I want to create one tree map per collection dynamically. With the current limitation, it would mean that I would have to limit the number of collections to, for example, 100 or 150. Not sure one would require as many collection but, given that I would have to set a limit, I thought about asking first.
This is actually the better design IMHO. The map is designed to grow to very large sizes, so I wouldn’t worry about optimizing this further (unless you have data to show that it’s very slow)
That’s a bit of the tricky part; I can’t know if the data to be shown are slow or not, but I can make the assumption that most often they are not. I really thought that design, using one big StableTreeMap, was a bad design, so it’s really good to know it’s probably the contrary.
Good, then, unless there is another use case, I guess we can consider this thread as answered. Thanks for the feedback.
There’s canbench for that 
Just documenting for my future self: this PR was my attempt to dynamically create a StableTreeMap. The feature works fine, but I created it before we discussed here that the best practice is actually to avoid doing so, therefore I closed it.