Add collateral, owner and voting addresses to masternode list table #3207
Conversation
|
@UdjinM6 did you also test this on mainnet regarding potential performance losses? |
|
I only tried changing filter back and forth to trigger list update first. The debug timer I added to logs showed an increase like from 150-200ms on avg to 200-250ms on avg which I wasn't able to notice by eyes. But now I tried reindexing... and it's dead... :/ |
|
Can't find any good solution to this besides just skipping updates until blockchain is synced and caching all the things but even then the first update takes like 1.5 sec which is way too much. Closing. |
|
@UdjinM6 storing the collateral address/destination in the MN object coming from the MN manager could be a viable solution. But then we need to take care of compatibility in evodb, not sure how much effort that'd be. |
|
Found smth :) |
|
I tested this by reindexing a couple of times and works pretty good it seems. MN list UI updates take ~200-300ms so calling them during reindex (and locking |
|
Holding |
|
Good idea 👍 Applied your patch, will test. |
|
@UdjinM6 any test results already? |
|
I tried reindexing a couple of time and And it differs from time to time - can take from 1 to 4 sec on my machine. |
|
How did you measure these times? |
|
|
Strange, I'm unable to reproduce the multi-second lag on startup with a fully synced wallet. Using the logging you provided I get just a few ms for each |
|
Ahh sorry, just realized that I probably shouldn't test this on testnet but on mainnet... 🙈 |
There was a problem hiding this comment.
tested ACK
The initial lag on my machine is much lower (a few 100ms instead of multiple secs). I assume this is dependent on hardware performance. I tend to accept this lag and then later perform a proper refactoring for this masternode list that utilizes caches and other tricks to speed up stuff.
|
No initial GUI lag after 79cbbd4 on my machine anymore: |
| @@ -831,6 +831,20 @@ void ThreadImport(std::vector<fs::path> vImportFiles) | |||
| // GetMainSignals().UpdatedBlockTip(chainActive.Tip()); | |||
| pdsNotificationInterface->InitializeCurrentBlockTip(); | |||
|
|
|||
| { | |||
| // Get all UTXOs for each MN collateral in one go so that we can fill coin cache early | |||
| // and reduce further locking overhead for cs_main in other parts of code inclluding GUI | |||
There was a problem hiding this comment.
Sigh.. I literally hate keyboard on recent macs more and more every day...
…ashpay#3207) * Add collateral, owner and voting addresses to masternode list table * Adjust column names in masternode list table * Slightly refactor updateDIP3List() * Lock cs_main in updateDIP3List early to avoid GUI frezes * Update MN list in GUI 10 times less often while blockchain is still syncing * Move GetUTXO calls outside of main update loop * Fill coin cache for masternode UTXOs on start
…ashpay#3207) * Add collateral, owner and voting addresses to masternode list table * Adjust column names in masternode list table * Slightly refactor updateDIP3List() * Lock cs_main in updateDIP3List early to avoid GUI frezes * Update MN list in GUI 10 times less often while blockchain is still syncing * Move GetUTXO calls outside of main update loop * Fill coin cache for masternode UTXOs on start Signed-off-by: cevap <[email protected]>
I did not notice any slowdown or GUI lags despite using
GetUTXOCoinhere (which lockscs_main), please test to see if that's the case for you too. This PR also tweaks table headers to match RPC output a bit better and unifies somewhat related code a bit.Thanks to Craig Durham for the suggestion.