Open oliver-sanders opened 6 months ago
IMO, the UI side of this issue is more concerning than the UIS side because UIS delay loads the server, whereas UI delay hits the user's browser.
The bulk of the time is being taken in the data store processing the deltas, this should be the first target for improvement. Profiling required to highlight problem areas, given that the table view is only slightly faster to load than the tree view, family tree computation is unlikely to be the cause.
1 - JS Profiling
Profile the time it takes to load the tree view for the workflow in the OP with hours
turned down to 20. Workflow is started in paused mode.
Results:
applyInheritance
.createTreeNode
and addChild
.The remainder appears to be vuejs.
2 - View Load Time
Open a view, then measure the time it takes to open the same view in a new workspace tab.
Manual timings to the nearest second:
3 - Component Loading
Start with the "simple tree" view and add in the components used by the regular "tree" view one by one, measuring the impact on load time for each.
<Task />
icons ~3s<Job />
icons ~4.5s
<v-btn />
buttons (used for expand/collapse) ~8.5s<v-icon />
icon (used for expand/collapse icons) ~11.5sUsing these timings to extract the cost per component:
<v-btn />
<Task />
<v-icon />
<Job />
Note: These costs are for 1'000 tasks, e.g 0.004s per <Task />
icon.
Conclusions
Remediation:
The three optimisations up so far make a reasonable dent in the CPU time.
The time is going into two places:
The data store time is more concerning than the view time as views can be optimised (e.g. table view reduces the number of nodes on screen by pagination, tree view can use a virtual scroller in the future to similar effect) but the data store time will always remain so the store should be the main target of optimisation.
This workflow has proven to be remarkably difficult for the UIS & UI to handle:
For more information see: https://cylc.discourse.group/t/slow-load-of-cylc-workflows-disconnects/823/19
Investigation so far has confirmed:
This issue focuses on the UI side of things.
Suggested remediation (UI only, please update with new suggestions):
O(n^2)
routine from the data store reducing the cost of nodes with a high number of children.