DO NOT MERGE: PoC for storing account, access_key
in memory
#12783
+178
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Profiles (e.g. the one linked here) have shown that
get_account
andget_access_key
make up for a significant amount of time inverify_and_charge_transaction
. This brought up the idea of storing accounts and access keys in memory.This PR implements a hacky proof of concept to measure an upper bound of gains achievable by storing accounts and access keys in memory. Why an upper bound? Because this implementation skips work like recording storage access for state witnesses. So this change here breaks many things, but it still allows successfully running the native transfer benchmark in a single-node, single-shard localnet.
There is no chance of ever merging this PR, so I just pushed the first iteration that works, assuming improving its code quality doesn't make sense.