[testnet] Remove the handling of the sizes.#5446
[testnet] Remove the handling of the sizes.#5446MathieuDutSik merged 5 commits intolinera-io:testnet_conwayfrom
Conversation
There was a problem hiding this comment.
It would be nice to avoid loading the old size maps over and over: we could stop loading them (and remove the fields in the View) or we could load them but clear the data for next time (if non-empty) in post_save.
There was a problem hiding this comment.
Well, in that case the post_load of `ByteMapView is just:
Ok(Self {
context,
updates: BTreeMap::new(),
deletion_set: DeletionSet::new(),
})So good news, nothing to load but bad news, we need a context, so we need a clone of it even if not used.
About deleting the data on storage. This can be done by adding a DeleteByPrefix in the code. However, we cannot test if what we delete is non-trivial without doing some expensive find_keys_by_prefix. So two realistic possibilities:
- Add a delete_by_prefix that may slow a little every operations.
- Make our mind with it and keep data that we do not need.
I left the code in Option 2, let me know if you want Option 1.
There was a problem hiding this comment.
Thanks for verifying. Yes we can leave the data around in storage. Can we delete the unused field from the view in this case?
There was a problem hiding this comment.
Yes, I was wrong. No need for those entries.
There was a problem hiding this comment.
nit: I wonder if we could remove #[allow(dead_code)] and write Hash = MIN_VIEW_TAG + 3 here
There was a problem hiding this comment.
Yes, we can though that does not impact the generated code.
ma2bd
left a comment
ma2bd
left a comment
There was a problem hiding this comment.
Not sure why CI is not green
…ue store view (#5671) ## Motivation Following PR #5446 the `write_batch` function has become sync but we have kept its status as async. This is incorrect, ## Proposal Remove the async property of `write_batch`and of other functions that should are in fact sync. ## Test Plan CI ## Release Plan On testnet_conway is the point here. ## Links None.
2 participants
Motivation
We are tracking the size of the keys in the smart contract. This is quite an expensive operation. This is
especially bad because we are not using this information.
Potentially, there are two usages:
Proposal
Remove the code that accesses the storages so as to get the speed increase.
However, the entries are kept in the
KeyValueStoreViewandKeyTagso as to ensure backward compatibility with already deployed contracts.Test Plan
CI.
Release Plan
There will be other issues to resolve
Links