Sphere Graph / Renderer speed decreased

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Running the latest version of Constellation
  • Attached the Support Package via Help > Support Package
  • Checked the FAQs: https://github.com/constellation-app/constellation/wiki/FAQ
  • Checked that your issue isn’t already filed: https://github.com/constellation-app/constellation/issues
  • Checked that there is not already a module that provides the described functionality: https://github.com/constellation-app/constellation/wiki/Catalogue-of-Repositories

Description

Lately I’ve noticed building sphere graphs - or more specifically rendering them has decreased drastically in performance. I feel like I used to be able to make a graph with 10000 vertices without issue. Now it takes what seems like minutes to render anything.

Steps to Reproduce

1. new graph
2. build sphere graph use 1000/10000 nodes to see the delays. Compare with other release versions.

Expected behaviour: loads fast

Actual behaviour: loads slow

Reproduces how often: 100%

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

[Nova-2119]

In the branch https://github.com/constellation-app/constellation/tree/performance/838-MultiThreading I have continued this ticket with a focus on multi-threading where possible to improve speed outcomes. Since then I have managed to multi-thread both the NodeLabelBatcher and the ConnectionLabelBatcher which has led to large improvements in rendering speed. The branch is still a work in progress, more work needs to be done to optimise the amount of threads being created and potentially improve upon the current implementation. Attached is an updated copy of the render time comparison with the latest rendering times in both the case where just NodeLabelBatcher is multi-threaded and both NodeLabelBatcher and ConnectionLabelBather are multi-threaded. Render time comparison.txt

[Nova-2119]

So it turns out the reason it is slower to open a graph multiple times is actually not due to opening a second graph but due having just closed a graph. Closing a graph calls the GraphRenderable.dispose() method which calls GLVisualProcessor.rebuild() which triggers a fullRefresh of the graph. This means that when you close the graph it actually rebuilds it in the background and never displays it to the screen. The slow down observed is actually it waiting for the refresh from the close to finish prior to performing a new refresh! This is why the times were roughly twice as slow and more variable, it’s doing the same thing twice and the amount of time between me closing the last graph and opening the new one explains the variability 😃

Some light digging showed me that reshape is called whenever a refresh should be performed, so I have moved the call to rebuild out of dispose and into that method. This has removed the slowdown affect and as far as I can tell everything behaves as it should.

I am doing some further investigating so that I can be sure that reshape is the correct method to call rebuild in, display() and init() are alternatives that might work. I need to become familiar with exactly when each is and isn’t called and how that correlates to when a refresh is and isn’t required. From names alone display feels like it should make more sense, but there’s more digging to be done to understand exactly what that does.

Render time comparison.txt