Fix performance issue in BsqWalletService #3177
Conversation
The updateBsqWalletTransactions method got called at each block for all transactions. During block download that wasted a lot of cpu and led to stuck UI thread and lost connections. The updateBsqBalance is not cheap (a few ms) and called for 100s of txs at each block was very problematic. Furthermore the listeners on the walletTransactions observableList got triggered which made the situation worse. We changed the observableList to a ArrayList and use a listener which gets called after the list is updated. We also make sure the onTransactionConfidenceChanged listener is not calling updateBsqWalletTransactions if bsq parsing is not complete and if the depth of the tx is > 1. In the updateBsqWalletTransactions method we use a flag and a delay to ensure that the updateBsqBalance is not called more then once in 100 ms. We changed also the getter to return a cloned version of the list to avoid potential concurrent modification exceptions at clients. Closes bisq-network#3175
|
Changes look reasonable but while running I notice that the
|
|
@sqrrm That is expected while block download as the chain tip gets updated with new blocks. The right one is from BitcoinJ, the left one the parsed blocks. |
|
@chimp1984 The right one should be the known block height from bitcoinj but it keeps changing, that's strange. |
If that is during block download it is expected, otherwise its a bug. I will test again. |
|
Just tested again but did the block download completed before parsing started. But taht way all was as expected. |
|
Made a video. The total used to be known at start, now it's changing, and the progress is not showing correctly.
|
|
@sqrrm |
The updateBsqWalletTransactions method got called at each block for all
transactions. During block download that wasted a lot of cpu and
led to stuck UI thread and lost connections.
The updateBsqBalance is not cheap (a few ms) and called for 100s of txs
at each block was very problematic.
Furthermore the listeners on the walletTransactions observableList got
triggered which made the situation worse.
We changed the observableList to a ArrayList and use a listener which
gets called after the list is updated.
We also make sure the onTransactionConfidenceChanged listener is not
calling updateBsqWalletTransactions if bsq parsing is not complete and
if the depth of the tx is > 1.
In the updateBsqWalletTransactions method we use a flag and a delay
to ensure that the updateBsqBalance is not called more then once
in 100 ms.
We changed also the getter to return a cloned version of the list to
avoid potential concurrent modification exceptions at clients.
Closes #3175