-
Notifications
You must be signed in to change notification settings - Fork 359
feat(cachekv): Optimize CacheKV by making SDK Upstream changes. #9
Conversation
Co-authored-by: Cal Bera <calbera@berachain.com> Signed-off-by: Devon Bear <itsdevbear@berachain.com>
Co-authored-by: Cal Bera <calbera@berachain.com> Signed-off-by: Devon Bear <itsdevbear@berachain.com>
Co-authored-by: Cal Bera <calbera@berachain.com> Signed-off-by: Devon Bear <itsdevbear@berachain.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can maybe remove the unsorted cache. Lock the tree and then do the tree insert in a gorontinue?
The tree should stay fairly small since it's just a single txn cache (atm) so there is a good chance the overhead of processing the opcode outweighs the tree insert + lock time and we get 0 lock contention and basically free parallelization
store/cachekv/store.go
Outdated
} | ||
|
||
// Clear the journal entries | ||
store.journalMgr = journal.NewManager() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has to be putting a heavy load on the garbage collected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember benchmarking this and getting a significant improvement with this line included. Without it, it seems garbage collector had more work to do and it had worse performance @itsdevbear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same reason the SortedCache is cleared on line 175
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@calbera what do you mean again here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically just including this line store.journalMgr = journal.NewManager()
increased benchmark speeds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as to the reason why, im not entirely sure, but I'm assuming that we basically help speed up the garbage collector by manually removing all pointers to the those journal CacheEntry
structs.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #9 +/- ##
==========================================
+ Coverage 69.04% 72.95% +3.91%
==========================================
Files 11 17 +6
Lines 365 880 +515
==========================================
+ Hits 252 642 +390
- Misses 107 228 +121
- Partials 6 10 +4
|
Co-authored-by: Cal Bera <calbera@berachain.com>
No description provided.