Speed up Vote Result display, cycle list item selection & JSON export

[stejbac]

Alleviate some hotspots displaying the Vote Result table (under DAO / Governance) for the first time after application startup, selecting a cycle list item to display the evaluated proposals for that cycle, and exporting the vote result history JSON. Also fix a bug in the JSON export, where the BSQ stake of each submitted ballot list was not added to the respective voteWeight fields in the JSON, with them incorrectly showing the merit alone (thus, many of the individual vote weights show as zero).

--

The two main hotspots revealed by profiling were the signature verification of each Merit object in the DAO state, when computing the merit totals, and searching the BSQ wallet for blind vote txs to determine if the user voted in the given cycle. The former hotspot affects JSON generation and the initial display of the cycle table the first time the Vote Result view is activated. The latter hotspot is revealed upon selection of a cycle in the table.

To alleviate the former hotspot, the merit calculations were parallelised when calling VoteResultView.doFillCycleList() upon view activation, and ensuring each Merit object is considered only once during JSON export, by moving merit calculations to the outer loop of VoteResultView.getVotingHistoryJson().

The latter hotspot was eliminated by replacing linear searches of the BSQ wallet for a given txId with a lookup into an added cached map, BsqWalletService.walletTransactionsById, as well as removing some needless looping over all the evaluated proposals of the cycle.

A third hotspot computing a map of ballots by proposal txId was eliminated from the cycle selection and evaluated proposal table display, by instead computing the map only once upon view activation, renaming the method VoteResultView.doFillCycleList() to doFillCycleListAndBallotMap().

--

Before the changes in this PR, JProfiler shows the following call tree when activating the view for the first time:

The best that I was able to do to speed this up was parallelise the merit calculations (and hence signature checking) somewhat. As the validity of the signatures affects the final merit sums, the expensive signature checks cannot easily be avoided.

--

Before the changes in this PR, JProfiler shows the following call tree when toggling between cycle list item selections ten times:

After the changes, the following call tree is seen instead:

As can be seen, most of the remaining hotspots are coming from JavaFX. (I tried to optimise the method GUIUtil.removeChildrenFromGridPaneRows to remove the next biggest hotspot, but was not really able to.)

--

Before the changes in this PR, JProfiler shows the following call tree when exporting the JSON:

It took more than six minutes, so I stopped profiling part way through. After the changes, the following call tree is seen instead:

Verifying Merit signatures is still the biggest hotspot, but now they are verified without repetition.

[boring-cyborg[bot]]

Thanks for opening this pull request!

Please check out our contributor checklist and check if Travis or Codacy found any issues with your PR. Also make sure your commits are signed, and that you applied Bisq's code style and formatting.

A maintainer will add an is:priority label to your PR if it is up for compensation. Please see our Bisq Q1 2020 Update post for more details.