Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(qt): refresh the whole wallet instead of processing individual updates for huge notification queues #5453

Merged
merged 2 commits into from
Jun 28, 2023

Conversation

UdjinM6
Copy link

@UdjinM6 UdjinM6 commented Jun 22, 2023

Issue being fixed or feature implemented

It's super slow for wallets with 100.000s of txes to process lots of notifications produced by rescan. Skip them all and simply refresh the whole wallet instead. In my case (500k+ txes testnet wallet) gui update after rescanblockchain time is down from forever to ~30 seconds. Same for wipewallettxes true (#5451 ). Gui update after wipewallettxes/wipewallettxes false is instant (cause there are no txes anymore) vs forever before the patch.

What was done?

refresh the whole wallet when notification queue is above 10K operations

actual changes (ignoring whitespaces): d013cb4?w=1

How Has This Been Tested?

running on top of #5451 and #5452 , wiping and rescanning w/ and w/out this patch.

Breaking Changes

should be none

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation
  • I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

@UdjinM6 UdjinM6 added this to the 20 milestone Jun 22, 2023
@UdjinM6 UdjinM6 changed the title feat(gui): refresh the whole wallet instead of processing individual updates for huge notification queues feat(qt): refresh the whole wallet instead of processing individual updates for huge notification queues Jun 22, 2023
ogabrielides
ogabrielides previously approved these changes Jun 25, 2023
Copy link
Collaborator

@ogabrielides ogabrielides left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

{
if (vQueueNotifications.size() - i <= 10) {
bool invoked = QMetaObject::invokeMethod(ttm, "setProcessingQueuedTransactions", Qt::QueuedConnection, Q_ARG(bool, false));
if (vQueueNotifications.size() < 10000) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you justify this magic number a bit more? why not 500 or 1k or 100k?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Processing 10K notifications worked ok-ish, with a slight delay for my 500k+ txes wallet. Processing 50-100k was already too slow comparing to refreshing the wallet instead. So I just kept 10k as a threshold. Could be higher or could be lower on different machines I guess, not sure how to pick the right number here.

Copy link
Member

@PastaPastaPasta PastaPastaPasta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK for squash merge; 1 nit

@@ -82,6 +83,7 @@ class TransactionTablePriv
}
}
}
parent->endResetModel();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it be a valid state of parent if an exception would be thrown before endResetModel() is called?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. Not sure I get the question.. What kind of exception? And why you think it should affect parent (TransactionTableModel*)?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://doc.qt.io/qt-6/qabstractitemmodel.html#endResetModel

You must call this function after resetting any internal data structure in your model or proxy model.

I see that some methods doesn't have noexcept specifier, more over functions between beginResetModel() and endResetModel() such as getWalletTxs, showTransaction have allocation inside: it means that any time an exception can be thrown.

There're two possible solution for resolve "you must call" request:

  • write a wrapper such as lock_guard that will call endResetModel() in a destructor.
  • wrap everything between begin & endResetModel to try-catch and safely call endResetModel

Copy link
Collaborator

@knst knst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

Copy link
Collaborator

@ogabrielides ogabrielides left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@PastaPastaPasta PastaPastaPasta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK for squash merge

@UdjinM6 UdjinM6 merged commit 7f40682 into dashpay:develop Jun 28, 2023
10 checks passed
@UdjinM6 UdjinM6 deleted the gui_huge_refresh branch June 28, 2023 16:00
UdjinM6 added a commit to UdjinM6/dash that referenced this pull request Jul 25, 2023
…pdates for huge notification queues (dashpay#5453)

## Issue being fixed or feature implemented
It's super slow for wallets with 100.000s of txes to process lots of
notifications produced by rescan. Skip them all and simply refresh the
whole wallet instead. In my case (500k+ txes testnet wallet) gui update
after `rescanblockchain` time is down from _forever_ to ~30 seconds.
Same for `wipewallettxes true` (dashpay#5451 ). Gui update after
`wipewallettxes`/`wipewallettxes false` is instant (cause there are no
txes anymore) vs _forever_ before the patch.


## What was done?
refresh the whole wallet when notification queue is above 10K operations

actual changes (ignoring whitespaces):
dashpay@d013cb4?w=1

## How Has This Been Tested?
running on top of dashpay#5451 and dashpay#5452 , wiping and rescanning w/ and w/out
this patch.

## Breaking Changes
should be none


## Checklist:
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e
tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository
code-owners and collaborators only)_
@UdjinM6 UdjinM6 modified the milestones: 20, 19.3 Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants