Cache results of isFiatCurrency and isCryptoCurrency

[chimp1984]

No description provided.

[stejbac]

I'm a little surprised there's much speedup, since the methods CurrencyUtil.get[Crypto|Fiat]Currency and Currency.getInstance are already memoised and the other steps in isCryptoCurrency and isFiatCurrency appear to be extremely cheap. Do you know know exactly where the bottleneck in the old version lies? I'm wondering if it could be in the catch (Throwable t) {...} path of isFiatCurrency, since it looks like the first three memoised methods don't cache their result in the case of an exception.

[chimp1984]

Thanks @stejbac for the review and comments!

I just did some measurments:
CurrencyUtil2 is the version from that PR, CurrencyUtil the master version.

With wrong Fiat, wrong crypto

CurrencyUtil2.isCryptoCurrency for 100000000 iterations took 1937 ms 
CurrencyUtil2.isFiatCurrency for 100000000 iterations took 1881 ms 
CurrencyUtil.isCryptoCurrency for 100000000 iterations took 2972 ms 
CurrencyUtil.isFiatCurrency for 100000000 iterations took 2134 ms 

With correct Fiat and crypto

CurrencyUtil2.isCryptoCurrency for 100000000 iterations took 1791 ms 
CurrencyUtil2.isFiatCurrency for 100000000 iterations took 1897 ms 
CurrencyUtil.isCryptoCurrency for 100000000 iterations took 2117 ms 
CurrencyUtil.isFiatCurrency for 100000000 iterations took 3572 ms 

With correct Fiat and crypto using concurrentHashMap in CurrencyUtil2

CurrencyUtil2.isCryptoCurrency for 100000000 iterations took 1752 ms 
CurrencyUtil2.isFiatCurrency for 100000000 iterations took 1777 ms 
CurrencyUtil.isCryptoCurrency for 100000000 iterations took 2121 ms 
CurrencyUtil.isFiatCurrency for 100000000 iterations took 3467 ms 

It seems the Currency.getInstance(currencyCode) is the "expensive" one.
The difference is not dramatic, so no strong opinion if we should merge that PR or close it. The methods are called very often so the 100M iteration is not totally crazy (2M times in a short profiling session without lot of UI interaction). To look why they are called that often would be another task, but I assume a big part are Comparators and that sums up quickly at list sorting operations.

[stejbac]

Yes, I think I recall the methods being a significant hotspot, when profiling the UI a while ago, so even small absolute speedups are probably worthwhile. The updated changes in the PR look fine to me.

utACK

[chimp1984]

Yes, I think I recall the methods being a significant hotspot, when profiling the UI a while ago, so even small absolute speedups are probably worthwhile. The updated changes in the PR look fine to me.

utACK

Yes, they are relatively easy and low risk, thats why I started on that beside other more complex ones like in the DAO domain...
A big part are item renderers not caching data but using viewModels as in offerBook. Will work on that as well but thats much more effort...

[sqrrm]

@chimp1984 tests are failing.

[sqrrm]

utACK on the changes

[sqrrm]

utACK