Closed Sword-Smith closed 8 months ago
Through d9eb6f02a66e5e8928cb765e8c462e6db0944644, 2b159cee871dd562a7edf1b81e98e1f3e5317f47, and 2b159cee871dd562a7edf1b81e98e1f3e5317f47, prune_abandoned_monitored_utxos
has been significantly improved. The new batch-getters in twenty-first
v0.36.0 really show their worth here, as we were able to move database reading out from a loop, such that the reading from the database happens only once, not $N$ or $N^2$ as was the case prior to these commits.
Amazing!!
Use batch-fetching of monitored UTXOs in resync_membership_proofs_from_stored_blocks
I've already done this in my big refactor. I'll see about back-porting it to current master.
Use batch-db interactions in all logic used to get dashboard-overview data
I'll need to review this. might already be done, as per above.
Request next block of batches after last has been received, or reduce interval with which batch-requests are made
I might need some clarification on this. You mean batches of blocks during sync? I will need to familiarize myself with how that presently works. Will touch base when ready to work on it.
alphanet-v5 is out with all these issues addressed.
This is a tracking issue intended to make Alphanet version 5 as streamlined as possible.
Version 0.0.5 is nigh. Let's attempt to iron out as many problems with the client as possible before we do
prune_abandoned_monitored_utxos
RPCrestore_monitored_utxos_from_recovery_data
in initialization process.If it's not possible, then add a flag allowing it to be skipped. As it's taken 15+ minutes on a specific node instanceresync_membership_proofs_from_stored_blocks