Short circuit the BigInteger arithmetic in 'AltcoinExchangeRate' &
'org.bitcoinj.utils.ExchangeRate' (from which the former is adapted), by
using ordinary long arithmetic when it is guaranteed not to overflow due
to the two quantities to be multiplied fitting in an int. This will be
the case most of the time. Also remove duplicated logic, to ensure that
all conversions of BTC amounts to volumes happen via the 'Price'
instance methods, so that the optimisation always applies.
In particular, this speeds up the BTC -> BSQ conversions in the burning
man view, as well as the USD price calculations for the candles in the
trades charts view via 'TradeStatistics3.getTradeVolume()'.
Additionally, fix the lazy initialisation pattern in TradeStatistics3 to
ensure that it is thread safe (that is, it only has benign data races),
by making it of the form:
Foo foo = this.foo;
if (foo == null) {
this.foo = foo = computeFoo();
}
return foo;
This avoids the problem that 'foo' is a nonvolatile field and can
therefore be seen to alternate any number of times between null and
nonnull from the PoV of the thread initialising it (at least when the
initialisation is racy).
Add an 'averagePricesValid' boolean field to avoid needless refilling of
the cached BSQ prices map when calling 'getAverageBsqPriceByMonth()'.
(Also skip a redundant filling of the map will non-historical data upon
startup of the service.) Since the prices are calculated from the
(observable) set of all trade statistics, add a listener to the set to
invalidate the cache whenever it changes.
This significantly speeds up the burning man view, since the getter is
called several times when activating it.
Factor out duplicated logic in the 'Stream.map' lambdas to compute the
BSQ value of the BTC of each streamed ReceivedBtcBalanceEntry, returned
as an 'Optional<Long>'. Also simplify the logic slightly and return an
OptionalLong instead for greater efficiency.
(Also replace a statement lambda with an expression lambda.)
Optimise 'BurningManPresentationService.getCandidateBurnTarget' to avoid
the repeated computation of the total accumulated decayed burned amount
for every listed burning man. To this end, cache the total in a nullable
Long field, along with the method 'getAccumulatedDecayedBurnedAmount()'
to lazily initialise it. (This eliminates a minor hotspot in the burning
man view revealed by JProfiler.)
Cache enum arrays 'TickUnit.values()' & 'PaymentMethodWrapper.values()'
as the JVM makes defensive copies of them every time they are returned,
and they are both being used in tight loops. In particular, profiling
suggests this will make 'TradeStatistics3.isValid' about twice as fast.
Now that the trade statistics are retrieved as a sorted set, it can be
assumed that the USD & BSQ trade lists passed to 'getUSDAverage' are
already sorted. Use this to avoid repeatedly scanning the USD trade list
for the first trade dated after each given BSQ trade, by moving two
cursors in a single pass across the respective lists simultaneously.
Make TradeStatistics3 implement the previously added ComparableExt
interface and make TradeStatisticsManager hold them as a TreeSet instead
of a HashSet, to support fast retrieval of statistics in any given date
range. (Even though red-black trees are generally slower than hash
tables, this should not matter here since the set is only being iterated
over and infrequently appended, and does not benefit from O(1) lookups/
additions/removals.)
Add a 'TradeStatisticsManager.getNavigableTradeStatisticsSet' accessor,
which returns the backing TreeSet of the current ObservableSet field, so
that callers can access its NavigableSet interface where needed (as
there is no ObservableSortedSet or similar in JavaFX). Use this to
optimise 'AveragePriceUtil.getAveragePriceTuple',
'DisputeAgentSelection.getLeastUsedDisputeAgent' and
'MutableOfferDataModel.getSuggestedSecurityDeposit', to obtain a narrow
date range of trade statistics without streaming over the entire set.
Additionally optimise & simplify the price collation in
'TradeStatisticsManager.onAllServicesInitialised', by exploiting the
fact that the statistics are now sorted in order of date (which is the
presently defined natural order).
Use a DoubleStream when streaming over 'List<Double>' method arguments
in InlierUtil, as well as a primitive array sort in 'InlierUtil.trim'
(followed by taking a sublist view), instead of calling 'Stream.sorted'.
To this end, use Guava 'Doubles.asList' to pass lists of Doubles to/from
the InlierUtil methods without incurring any boxing or unboxing costs,
since their spliterators can be simply downcast to Spliterator.OfDouble
(opportunistically), instead of needing to use 'mapToDouble' to unbox.
This was a minor hotspot when called from AveragePriceUtil (used by the
burning man and BSQ dashboard views).
Use nonstrict bounds when filtering outliers from the provided trade
statistics list, since otherwise it will always remove the outermost two
inliers from the list. This is because the dependent call to
'InlierUtil.findInlierRange' returns the min & max inlier values.
Use a Map to speed up 'PaymentMethod.getPaymentMethod', called from
'isValid', instead of scanning the payment method list every invocation.
Make the list immutable to ensure the map never goes stale, which is OK
since no code modified it outside PaymentMethod's static initialisation.
Also speed up the global accessor 'TradeLimits.getMaxTradeLimit', by
caching the DAO param value in a volatile field, cleared upon each new
block arrival.
Furthermore, speed up 'TradeLimits.getFirstMonthRiskBasedTradeLimit' by
simplifying the rounding logic to avoid a pass through the (rather slow)
BigDecimal type.
Short circuit the exception control flow used in the method
'TradeStatistics3.getPaymentMethodId', which occurs whenever the payment
method code is stored directly in the 'paymentMethod' field instead of
first being converted into a numeric string. This occurs if the method
is unrecognised as it is not in listed into 'PaymentMethodWrapper' enum.
This fixes an unnecessary slowdown of 'TradeStatistics3.isValid', which
calls the above, when scanning the list of BSQ trade statistics in
AveragePriceUtil and elsewhere, due to the fact that the 'BSQ_SWAP'
payment method has been missed out of the above enum.
Also add a (presently disabled) unit test to prevent any future payment
methods from being missed out of the enum. (Should fix the missing BSQ
swaps issue in a separate PR to make sure that the seed nodes recognise
the new payment method code before anyone else.)
Change flow of cloning an offer:
We open the clone offer tab similar like the duplicate/edit offer tab. When clicking the clone button we create and publish the cloned offer. if the clone would not have changed the payment method/currency we show a popup and deactivate the offer.
At editOffer we check if the offer is using a shared maker fee and if so we check if the edit triggered same payment method/currency. If so we show a popup and deactivate the offer.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
btcWalletService.getAddressEntriesForOpenOffer() contains also OFFER_FUNDING entries.
This version minimizes the change by mapping to address and use distinct to avoid duplicate entries to be summed up.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Multiple calls will call add on the hashset but as the entry is the same it will not trigger any change of the hashset.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
The numTransactions param in getRecentTransactions delivers all transactions if it is 0 but that is not intuitive. Passing Integer.MAX_VALUE makes more sense.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
We use a postfix to the header title and not a busy animation, as the busy animation is quite CPU intense.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
We do not add a column to the overview table because calculating the balance entries is expensive and doing it over all burningmen would take too long. There is headroom for performance improvements in that area...
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Make 'FormattingUtils.formatDateTime(Date, boolean)' two or three times
faster by caching the 'java.text.DateFormat' objects used to format the
given date & time in either the local or UTC time zone. Since these
formatters are not thread safe (though they may be reused), use a
ThreadLocal to store them (as a tuple, along with the current locale to
make sure it hasn't changed since the last invocation).
This is a minor hotspot for the Transactions view load, since the date
strings in TransactionsListItem are formatted eagerly (via DisplayUtils)
for the purpose of filtering the items by substring match. (Other list
views seem to format dates lazily, though it's possible that there will
be speedups elsewhere in the UI.)
Multiple threads read and write to the accounting blocks list causing
data races. Luckily, the LinkedList threw a ConcurrentModificationException
to limit damage. Now, a ReadWriteLock protects the LinkedList against
data races. Multiple threads can read the list at the same time but only
one thread can write to it. Other writing threads wait until it's their
turn.
Fixes#6545
Add a third cache to WalletService, cleared upon wallet change events,
which maps txIds to txs. This allows the speedup of repeated calls to
'WalletService.getConfidenceForTxId', by avoiding the need to copy and
scan the entire set of wallet txs to find the one with matching id,
for each method invocation.
This is mainly to provide a further speedup to the closed-trades-view
load, by making it much faster to filter the list of BSQ swap trades by
tx confirmation status in 'ClosedTradesDataModel.applyList' and
'ClosedTradesManager.getNumPastTrades'.
Reduce a bottleneck in the closed-trades-view load & table scrolling,
caused by a call to 'ClosedTradesManager.getNumPastTrades' for each
list item displayed. This repeatedly scans the entire collection of
closed trades and BSQ swap trades, in order to count all those which
share a given peer node address. (Scanning the BSQ swap trades is
particularly slow due to their filtering by tx confirmation status.)
To this end, cache the counts of trades by peer node address with a
nullable Multiset field in ClosedTradesManager & BsqSwapTradeManager,
so that the trades are scanned at most once when the view loads. Add
listeners to clear the respective cache when the trade list changes or
the BSQ wallet txs change.
The DaoStateStorageService submits tasks to a daemon thread executor
service. The JVM continues to execute threads until all non-daemon
threads have terminated. So the JVM will kill the DaoStateStorageService
during write requests leading to data corruption.
This change uses a non-daemon thread executor service at waits during
shutdown until all data is written to disk.
One seed node using the ExportJsonFilesService had RejectedExecutionExceptions as before we had only permitted a thread pool queue capacity of 1.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Add map for maintaining pending protocols by offerID.
Fixes a bug when the same taker got an early failure in a take offer attempt before the maker removes the offer and the taker did not persist the failed trade, thus the protection to not be permitted to take the same offer after a failure does not prevent another take offer attempt of the same taker. In such a case the maker has the old pending protocol listening for the trade messages and both the old and new protocol instance process those messages. In case the model data has changes (e.g. diff. inputs) this can cause a failed trade.
We do not remove the message listeners on failures to tolerate minor failures which can be recovered by resend routines.
There could be more solid fixes for that issue but this approach seems to carry less risks.
Use AvailabilityResult.INVALID_SNAPSHOT_HEIGHT instead of AckMessage with error.
Show description in error popup instead of enum name.
Return PRICE_CHECK_FAILED instead of UNKNOWN_FAILURE at error at price check also for non api users.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
This helps to avoid that the legacy BM would get the rest in case there are capped shares.
It still can be that a candidate exceeds the cap and by the adjustment becomes capped. We take that into account and the legacy BM would get some share in that case.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Left side is amount to burn to reach the max allowed receiver share based on the burned amount of all BM.
The right side is the amount to burn to reach the max allowed receiver share based the boosted max burn target.
Increase ISSUANCE_BOOST_FACTOR from 3 to 4.
Add help overlay to burn target table header.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
This was likely a major bug for seed nodes that at sending hash responses the main thread got blocked.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
