feat(Jurnal): Accounts saved in index map. #2878
Conversation
CodSpeed Performance ReportMerging #2878 will degrade performances by 7.38%Comparing Summary
Benchmarks breakdown
|
rakita
changed the title
| fn sload( | ||
| &mut self, | ||
| address: Address, | ||
| address_or_id: AddressOrId, |
There was a problem hiding this comment.
Interface got changed so it now can process both account id or address.
Account id is obtained on loading of the account and it can be used to fetch the account faster from journal.
| } | ||
|
|
||
| /// Warms the coinbase account. | ||
| fn warm_coinbase_account(&mut self, address: Address); |
There was a problem hiding this comment.
We can load coinbase from the start and make it warm (if needed), as fetching it in post execution state is going to be fast with account id.
| fn get_account(&mut self, account_id: AccountId) -> (&Account, AddressAndId); | ||
|
|
||
| /// Sets the caller id. | ||
| fn set_caller_address_id(&mut self, id: AddressAndId); |
There was a problem hiding this comment.
Caller/coinbase/txtarget addresses and ids are saved in Journal so they can be fetched on demand.
| ) -> Vec<(Address, TransitionAccount)> { | ||
| let mut transitions = Vec::with_capacity(evm_state.len()); | ||
| for (address, account) in evm_state { | ||
| for (account, address) in evm_state.take_accounts().into_iter().flatten() { |
| let auth_acc = state.get(&signer.address()).unwrap(); | ||
| assert_eq!(auth_acc.info.code, Some(Bytecode::new_eip7702(FFADDRESS))); | ||
| assert_eq!(auth_acc.info.nonce, 1); | ||
| println!("state: {:#?}", state); |
There was a problem hiding this comment.
| println!("state: {:#?}", state); |
Journal function now contain
AddressOrIdfield that allow fetching account by or or by addressOutput state is now a index map, that contains pages of accounts and hashmap that maps address to the index.
Analysis:
codspeed times are very slower than running on machine but even with them we can see order of magnitude difference between transfer and CALLs. 1000tx transfers with commit take 2.8ms that means one transfer is 2.8us and degradation is 0.2us per transaction, while 50 CALLs are 97us and it is improved to 91 µs
And when i run this on machine,
revme bench transfer-multiI gettransact_commit_1000txstime:[387.81 µs 393.68 µs 398.68 µs]which means on the real machine it is 0.4us per transaction and diff is 0.05us or 50ns .For context 50ns degradation for 3 billion transactions (number of mainnet transactions) are few (two/three) minutes of difference.
My conclusion is even if transact_commit_1000tx is worse by 7%, an improvement of 7% for CALL or %5 SSTORE is worth a lot more.