After #202 now we have a great optimizations with the neo limits, so.. this issue is more related to the standard, and the learning curve.
I think that we should have a limit memory for the SmartContract, instead of MaxItemSize. I think that for the developer, it will be easier if they only need to know that he have 8Mb of memory per execution. It'ts hard to explain to a new user that he can't have one byte array[2049] but he can have 1000 byte arrays of 2048.
The developer need to know how the VM it works. If we limit according to the used memory, we can unify the VM behaviour as the most common behaviors, and we can remove MaxItemSize limit.
Cons:
- Define how much memory per reference (in a deterministic way)
- Calculate the memory size for certains types (Maps)
- Speed is not improved.
- Backward incompatible.
Pros:
- More fair.
- Easy to understand for users and developers.
- We can remove
MaxItemSize limit.
It's worth?
After #202 now we have a great optimizations with the neo limits, so.. this issue is more related to the standard, and the learning curve.
I think that we should have a limit memory for the SmartContract, instead of
MaxItemSize. I think that for the developer, it will be easier if they only need to know that he have 8Mb of memory per execution. It'ts hard to explain to a new user that he can't have one byte array[2049] but he can have 1000 byte arrays of 2048.The developer need to know how the VM it works. If we limit according to the used memory, we can unify the VM behaviour as the most common behaviors, and we can remove
MaxItemSizelimit.Cons:
Pros:
MaxItemSizelimit.It's worth?