Call operation performance optimizations #5537
Conversation
A series of collections that can be rolled back to a prior state. Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
- Move values that are the same or shared across the transaction to TxValues record - Move warm and cold storage to undoable sets and tables. - Move transient storage to undoable table. - Move address hashing inside of address with a memoized field. - lazy create EOF return stack Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
|
|
8%->80% performance improvement in the call/delegate call operation, respecitivly. call delegate call |
| /** The constant ZERO. */ | ||
| public static final Address ZERO = Address.fromHexString("0x0"); | ||
|
|
||
| static LoadingCache<Address, Hash> hashCache = |
There was a problem hiding this comment.
we don't want to add a limit for this cache ?
There was a problem hiding this comment.
What limit would you suggest?
There was a problem hiding this comment.
I would say a maximum size. Maybe we should see how much on average we load hash by block and got a number. But with a cache without max seems dangerous to me . Or else there is a default limit?
|
|
||
| mark = subject.mark(); | ||
| // non-existent remove doesn't advance mark | ||
| subject.remove("Bonjour"); |
| private Address address; | ||
| private final Supplier<Hash> addressHash = | ||
| Suppliers.memoize(() -> address == null ? Hash.ZERO : Hash.hash(address)); | ||
| Suppliers.memoize(() -> address == null ? Hash.ZERO : address.addressHash()); |
There was a problem hiding this comment.
is it still need to have memoize in this case ?
There was a problem hiding this comment.
I applied it to all cases where we saw Hash.hsah(addres)) to be consistant.
When I look to the CPU profiling in case of Call operation, I see roughly the same percentage in samples pre and post this PR, around 63%. Is it the right screenshot ? Am I missing something ? |
|
I'm still reviewing the PR, meanwhile I installed this PR on a Mainnet node to test the performance improvement compared to main branch |
Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
|
Assuming sampling is at the same fixed interval, the CALL samples had 3190 pre and 2943, so pre had 8.39% more samples. for DELEGATECALL the change was more dramantic at 4152/2249, so pre had 84.61% more samples. I'll get my CartEVM results tomorrow. Total time decreased, not so much share of computation. I also don't have a good "tower" call benchmark (where we do 1000 deep callstacks). I'll dig into reference tests for a good example. That is where I expect the most payback for undo collections. What surprised me is just how much time is spent in the call frame init as opposed to other work steps. |
|
I also want at a day of fuzzing before it gets committed.
|
|
Tower call results are unimpressive, so given the breadth of the change I'm going to shelve it as not worth the risk. pre post Berlin is where access lists were introduced and is where the showdown is. If actual on-chain gas limits are used (due to 63/64) stats are much better, but only a 70 high tower gets built - the reference test case pre post |
|
Address hash caching may be an independently useful optimization. |
Merge main, post 4844 changes Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
Call ops are still the worst performers, so raising the floor is worth the hit to a lesser used top performing operation. |
|
A week of fuzzing had no findings |
* Call Operation performance improvements - Move values that are the same or shared across the transaction to TxValues record - Move warm and cold storage to undoable sets and tables. - Move transient storage to undoable table. - Move address hashing inside of address with a memoized field. - lazy create EOF return stack Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
* Call Operation performance improvements - Move values that are the same or shared across the transaction to TxValues record - Move warm and cold storage to undoable sets and tables. - Move transient storage to undoable table. - Move address hashing inside of address with a memoized field. - lazy create EOF return stack Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
* Call Operation performance improvements - Move values that are the same or shared across the transaction to TxValues record - Move warm and cold storage to undoable sets and tables. - Move transient storage to undoable table. - Move address hashing inside of address with a memoized field. - lazy create EOF return stack Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>
* Call Operation performance improvements - Move values that are the same or shared across the transaction to TxValues record - Move warm and cold storage to undoable sets and tables. - Move transient storage to undoable table. - Move address hashing inside of address with a memoized field. - lazy create EOF return stack Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com> Signed-off-by: garyschulte <garyschulte@gmail.com>
* Call Operation performance improvements - Move values that are the same or shared across the transaction to TxValues record - Move warm and cold storage to undoable sets and tables. - Move transient storage to undoable table. - Move address hashing inside of address with a memoized field. - lazy create EOF return stack Signed-off-by: Danno Ferrin <danno.ferrin@swirldslabs.com>





PR description
TxValues record
Fixed Issue(s)