Use trie-cache for validate_block
#2813
Conversation
skunert
added
B0-silent
| fn as_trie_db_mut_cache(&self) -> Self::Cache<'_> { | ||
| SimpleTrieCache { | ||
| value_cache: self.value_cache.borrow_mut(), | ||
| node_cache: self.node_cache.borrow_mut(), | ||
| } | ||
| } |
There was a problem hiding this comment.
This function is called when we call storage_root. The values that are being created while calculating the storage_root should not be added to the value_cache as otherwise they may would overwrite some cached value from the "real trie" (we only distinguish using the key and the key stays the same in each trie). If another operation then would want to fetch this overwritten value, it would get some invalid data.
The nodes are accessed by their hash, so that should be no problem. However, the question in general is if we even need to cache these nodes. These nodes will never be accessible from the "storage root" we are operating on.
There was a problem hiding this comment.
The value cache is now disabled when building storage roots. Due to how get_or_insert_node works I think it does still make sense to take ownership of the fetched node and cache it.
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Davide Galassi <davxy@datawok.net>
Co-authored-by: Anton <anton.kalyaev@gmail.com>
|
bot merge |
|
Waiting for commit status. |
Follow up of paritytech/substrate#14403
Closes #2432
This PR adds a simple trie-cache to the validate_block function. In contrast to the trie-cache in substrate there is only a single value and a single node cache here, as proposed in #2432.
The
ReadOnceBackendis not included, I think we can be conservative and just have the cache for now.Performance improvements
For the validate_block benchmark, we see a roughly 10% improvement. The benchmark using glutton is not benefiting from the cache at all, since no values are accessed twice.