Table of motors: optimize startup performance of OPI-based ToM

[Tom-Willemsen]

As an instrument scientist I do not want to have performance regressions in the table of motors.

We are trying to move to an OPI-based ToM in #4633 . As noted in the comments of that ticket, the performance of the OPI based solution is about 3x slower than the java-based implementation that we had previously when initially opening the ToM.

Possible solutions:

• Reduce the number of scripts within the OPI by doing the logic in java code and writing to a CSS local PV
• See also Dom's comment below

Acceptance criteria:

• The performance of opening the OPI based ToM on an instrument-like machine (e.g. DEMO or SCIDEMO) is comparable to the previous performance of the java based solution.

[DominicOram]

Possible things that could help:

• Reduce the number of scripts/rules
• Use one large OPI rather than linking containers
• Create a motor widget in CSS
• Use threading in any scripts

[Tom-Willemsen]

Initial investigation:

• Scripts/rules don't appear to be the primary issue - I tried completely removing all of the scripts and rules and only saw a minor performance increase.
• I tried copying widgets into the top-level OPI rather than using linking containers - this had no effect as far as I could tell.
  • These were also all pointing at the same motor, so I don't think the underlying PV connections are what is taking the time here.
• I tried substituting the grid layout for a row based mechanism, in case CSS was taking a long time calculating a layout. This did not significantly change the performance.
• I removed half of the motor widgets in the table of motors and the performance became ~2x better
  • With a single motor widget on screen performance was good

This leads me to believe that the primary performance issue here is the sheer number of widgets being drawn.

[John-Holt-Tessella]

Is this inside a linking container? If you remove them from the linking container is it better?
If you remove the icons is it better?
We have lots of labels on the reflectometry page and that doesn't seem so bad. I am not sure how many though. (No icons)

[Tom-Willemsen]

Is this inside a linking container?

No, in point 2 above I removed all linking containers and copied them into the top level, this had little to no performance impact

If you remove the icons is it better?

If I remove the 5 icon widgets for each motor the performance becomes 2x better, which is in line with the performance being based on total number of widgets.

We have lots of labels on the reflectometry page and that doesn't seem so bad.

For comparison:
Eurotherm: 58 widgets
ICE fridge (with complex schematic): 92 widgets
Reflectometry front panel: 135 widgets
CS-Studio "large" performance test: 200 widgets
Table of motors OPI: 674 widgets

[John-Holt-Tessella]

Ahhh, ok, brilliant. OK unless anyone else has a better plan I think it is back to Java. But I feel we have learned something.

[DominicOram]

If we create a specific motor widget in CSS we could cut the number of widgets down significantly

[Tom-Willemsen]

@DominicOram yes, that's the approach I was thinking of taking to continue onwards with this ticket.

[Tom-Willemsen]

In a discussion with @ThomasLohnert and @DominicOram about different ways of implementing this in CSS, we have come to the conclusion that we should go back to a java-based table of motors for now.

I'll write up what we found in this ticket on the wiki.

Edit: added at https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/OPI-programming-tips-and-limitations