feat: reduce block overhead effect on estimations #7175
Conversation
1. Use account ids without a shared prefix. 2. Subtract block overhead instead of just checking it is insignificant. resolves near#7003
|
This change increases the unique DB accesses by about 50% in |
|
Oh and most importantly, now the block size of 10 gives the same results as block size of 100. (Reducing it down to 1 still makes a difference but it is no longer 2x, it is more like 1.3x and it is almost invisible for block_size > 3.) |
| use std::path::{Path, PathBuf}; | ||
| use std::sync::Arc; | ||
|
|
||
| fn get_account_id(account_index: u64) -> AccountId { | ||
| AccountId::try_from(format!("near_{}_{}", account_index, account_index)).unwrap() |
There was a problem hiding this comment.
FWIW, never understood why we account-index twice here.
There was a problem hiding this comment.
Yeah it's a bit weird. It's to make it longer I suppose, as the account name length does matter quite a bit for how deep in a trie it can be.
Not sure if it was intentional by whomever designed this but this creates somewhat interesting paths for every account that look something like this:
- extension node from root to "near_"
- several branches to get through first account index
- another extension for the second index
Almost the same thing could be achieved with "near_{account_index}_blablabla". But now there is a potential of sharing the extension node, as the state will be the same for all accounts and I think they will produce the same hashes.
Honestly, I don't think it matters. But let's not swap out too many gears at once.
Interesting point! I guess it could lead to smaller branch trie nodes. Maybe other things as well, I haven't thought about it too much. But yeah, definitely I will take a close look at the changes tomorrow. |
In near#7175 the subtraction of block overhead was introduced wrong. Instead of subtracting it once per block, it was subtracted once per transaction within the block. This leads to subtraction underflows that also showed up in the continuous estimation.
In near#7175 the subtraction of block overhead was introduced wrong. Instead of subtracting it once per block, it was subtracted once per transaction within the block. This leads to subtraction underflows that also showed up in the continuous estimation.
In near#7175 the subtraction of block overhead was introduced wrong. Instead of subtracting it once per block, it was subtracted once per transaction within the block. This leads to subtraction underflows that also showed up in the continuous estimation.
In #7175 the subtraction of block overhead was introduced wrong. Instead of subtracting it once per block, it was subtracted once per transaction within the block. This leads to subtraction underflows that also showed up in the continuous estimation.
resolves #7003