Steven Barclay db26a1fe2d Optimise TransactionAwareTrade.isRelatedToTransaction ... Attempt to remove a bottleneck during the transactions view load, as revealed by JProfiler, by optimising the code to determine if any given transaction and trade are related. Since both these sets will tend to grow linearly with time, causing quadratic slowdown of TransactionsView, try to alleviate (without completely fixing) the problem. To do this, add a cached set of disputed trade IDs to DisputeListService so that TransactionAwareTradable.is(Dispute|RefundPayout)Tx can be made O(1) in the common case that the given trade is not involved in any dispute. Also avoid calling Sha256Hash::toString by passing tx IDs as Sha256Hash objects directly to is(Deposit|Payout)Tx, and short circuit an expensive call BtcWalletService.getTransaction in isDelayedPayoutTx, in the common case, by pre-checking the transaction locktime. This also fixes a bug in isRefundPayoutTx whereby it incorrectly returns false if there are >1 disputes in the list returned by RefundManager but the given trade is not involved in the last one.		2021-01-26 20:10:47 +00:00
..
.tx
src	Optimise TransactionAwareTrade.isRelatedToTransaction	2021-01-26 20:10:47 +00:00
update_translations.sh	Update translations for v1.5.0 and adding Czech and Italian	2020-11-09 09:18:47 +01:00