perf(client, host): redundant state caching #59
Conversation
There was a problem hiding this comment.
I agree with your point on the witnessdb -- this is a really good catch that will probably save a lot of cycles. Left some small nits, also going to ask in the revm telegram any performance differences between database and databaseref. Because at this point, maybe we can just make WitnessDB a Database instead of DatabaseRef, but I'm not sure how good that is.
crates/executor/host/src/lib.rs
Outdated
There was a problem hiding this comment.
There's an unused import in this file according to the linter
crates/storage/rpc-db/src/lib.rs
Outdated
| use reth_storage_errors::{db::DatabaseError, provider::ProviderError}; | ||
| use revm_primitives::HashMap; | ||
|
|
||
| /// A database that fetches data from a [Provider] over a [Transport]. | ||
| /// | ||
| /// This type is very similar to a CacheDb as exposed by revm, except we have some extra fields |
There was a problem hiding this comment.
You can say that the caching part is similar, but the RpcDB actually uses an RPC to fetch the state, which is pretty different from the CacheDB which is just a wrapper.
|
adjusted comment + lint |
I think compared to the current wrapper it'll save a deref |
Background
Typically,
CacheDbis used when reads from the underlyingExtDBare expensive. This cache represents the state at the beginning of the block, any state changes actually happen in a wrapper around theDB: Databasetype.Internally CacheDB just stores queries in a memory map.
Client
In the client,
CacheDBwill make everything more expensive because the underlying witnessdb is really cheap to read from, soCacheDBdoes a clone that is not needed for every read.Host
In the host, the
RpcDBtype does almost everything theCacheDBwould do, this means. things like storage slots are saved twice in memory.With minimal changes
RpcDBwe can replicate all theCacheDBbehavior, and instead implDatabaseand we can pass a &mut of it to the executor.