core/state: remove slot dirtyness if it's set back to origin value #29731
Conversation
rjl493456442
force-pushed
the
filter-noop-storage-update
branch
from
851912f to
5005f21
Compare
karalabe
left a comment
karalabe
left a comment
There was a problem hiding this comment.
LGTM, lets see what benchmarkers say
holiman
left a comment
holiman
left a comment
There was a problem hiding this comment.
We could fix it here, but with the kind of journal that we have now, where we just linerarly pile events on events, it's not "free".
Might make sense to either apply this later on, in a non-linear journal, OR to do this check later on, during commit (?)
|
I would prefer to fix it there, namely the storage we finalize are truly dirty. It's a cleaner solution that we can make sure in each transaction frame the storage changes are correct and then we only need to care about the logic for merging the storage changes between different frames. |
|
Bench07: PR Overall performance is basically same. 
Prefetch storage waste is also same. It means the scenario fixed by this pull request (storage is modified and then set back to its original value within the same transaction) doesn't happen a lot. 
|
…thereum#29731) * core/state: remove slot dirtiness if it's set back to origin value * core/state: suggestion from martin
3 participants
This pull request reworks the dirty storage logic a bit, by handling one more corner case for revoking dirtiness.
The dirty marker of a storage slot will be revoked in these following two cases:
In these two cases, the storage slot shouldn't be regarded as dirty anymore.