Refactor refreshing ztx conf counts #34

Open
opened 3 years ago by duke · 1 comments
duke commented 3 years ago
Owner

The current code for refreshing confirmation counts for ztx's is extremely inefficient, it does a gettransaction call on every single ztx in the history of the wallet, to update the current confirmations count. No user actually cares about the conf count, except to know if it's unconfirmed, confirmed or notarized.

So we are spending a massive amount of CPU every few seconds, slowing down the GUI, in wallets with many transactions.

A better GUI would show simply unconfirmed/confirmed/notarized, and only when viewing individual transaction details would we show exact confirmation counts. In my experience, users do not care about the confirmation counts of old transactions at all. We should not slow down our GUI rendering them all the time.

The current code for refreshing confirmation counts for ztx's is extremely inefficient, it does a gettransaction call on every single ztx in the history of the wallet, to update the current confirmations count. No user actually cares about the conf count, except to know if it's unconfirmed, confirmed or notarized. So we are spending a massive amount of CPU every few seconds, slowing down the GUI, in wallets with many transactions. A better GUI would show simply unconfirmed/confirmed/notarized, and only when viewing individual transaction details would we show exact confirmation counts. In my experience, users do not care about the confirmation counts of old transactions at all. We should not slow down our GUI rendering them all the time.
duke commented 1 year ago
Poster
Owner

Using "getalldata" RPC would make things much faster

Using "getalldata" RPC would make things much faster
duke added the
bug
label 1 year ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.