[bisq-network/bisq] Speed up DAO state monitor view load (#4035)

Steven Barclay notifications at github.com
Mon Mar 9 08:50:01 UTC 2020

- make yourself familiar with the CONTRIBUTING.md if you have not already (https://github.com/bisq-network/bisq/blob/master/CONTRIBUTING.md)
- make sure you follow our [coding style guidelines][https://github.com/bisq-network/style/issues)
- pick a descriptive title
- provide some meaningful PR description below
- create the PR
- in case you receive a "Change request" and/or a NACK, please react within 30 days. If not, we will close your PR and it can not be up for compensation.
- After addressing the change request, __please re-request a review!__ Otherwise we might miss your PR as we tend to only look at pull requests tagged with a "review required".

Compute height cells lazily to speed up `DaoStateMonitorView`

Avoid a bottleneck computing the cycle index & calling `Res.get(..)` for every block since genesis in the DAO state monitor view, when building the `DaoStateBlockListItem` objects, by making the `height` field lazy. To do this, pass the cycle index into the constructor using an `IntSupplier` and make the height a memoised `Supplier<String>` with a custom getter.

Also add a unit test to check that the auto-generated `equals` & `hashCode` methods still work as expected, as it isn't totally clear what Lombok would do when a field type differs from its getter return type.


Flippling back and forth between the _Network monitor_ tab and the _Governance_ tab revealed the following call tree in JProfiler:

![Screenshot from 2020-03-06 10-16-21](https://user-images.githubusercontent.com/54855381/76194185-9b2b4080-6220-11ea-911d-73f6df162636.png)

As can be seen above, most of the time is spent in the stream pipeline collecting new `DaoStateBlockListItem` objects, in `DaoStateMonitorView.onDataUpdate`. After the change, the main bottleneck appeared to be from internal JavaFX code, in the `listItems.setAll` call in `onDataUpdate` (perhaps from one of the listeners on `DaoStateMonitorView.sortedList`). However, I believe there was a noticeable speedup. Also, the slowdown over time is likely to be quadratic without the change, as the number of cycles and block grows linearly. (The main bottleneck appears to be computing the cycle index of each block.)

You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * Avoid raw use of Overlay<T>
  * Compute height cells lazily to speed up DaoStateMonitorView

-- File Changes --

    M desktop/src/main/java/bisq/desktop/main/MainViewModel.java (22)
    M desktop/src/main/java/bisq/desktop/main/dao/monitor/StateBlockListItem.java (31)
    M desktop/src/main/java/bisq/desktop/main/dao/monitor/daostate/DaoStateBlockListItem.java (7)
    M desktop/src/main/java/bisq/desktop/main/dao/monitor/daostate/DaoStateMonitorView.java (25)
    M desktop/src/main/java/bisq/desktop/main/portfolio/pendingtrades/steps/TradeStepView.java (3)
    A desktop/src/test/java/bisq/desktop/main/dao/monitor/daostate/DaoStateBlockListItemTest.java (63)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200309/899371bc/attachment.html>

More information about the bisq-github mailing list