Table CPU Performance Improvements

[jvigliotta]

Closes
partial-close: #7268 (items 2, 3)

Describe your changes:

Two main changes here:

• make non-reactive rows to reduce memory usage
• throttle updates to the table to 1 second to minimize redraws

These changes resulted in a significant (100%+ -> 35%~) decrease in CPU usage.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Is this change backwards compatible? For example, developers won't need to change how they are calling the API or how they've extended core plugins such as Tables or Plots.

Author Checklist

• Changes address original issue?
• Tests included and/or updated with changes?
• Has this been smoke tested?
• Have you associated this PR with a type: label? Note: this is not necessarily the same as the original issue.
• Have you associated a milestone with this PR? Note: leave blank if unsure.
• Is this a breaking change to be called out in the release notes?
• Testing instructions included in associated issue OR is this a dependency/testcase change?

Reviewer Checklist

• Changes appear to address issue?
• Reviewer has tested changes by following the provided instructions?
• Changes appear not to be breaking changes?
• Appropriate automated tests included?
• Code style and in-line documentation are appropriate?

[codecov]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (3e31bbe) 56.02% compared to head (e4e3b7a) 55.98%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7392      +/-   ##
==========================================
- Coverage   56.02%   55.98%   -0.05%     
==========================================
  Files         662      662              
  Lines       26302    26304       +2     
  Branches     2551     2551              
==========================================
- Hits        14737    14727      -10     
- Misses      10856    10865       +9     
- Partials      709      712       +3     

Flag	Coverage Δ		*Carryforward flag
e2e-full	42.03% <ø> (ø)		Carriedforward from 3e31bbe
e2e-stable	59.91% <ø> (-0.01%)	⬇️
unit	48.98% <25.00%> (+<0.01%)	⬆️

*This pull request uses carry forward flags. Click here to find out more.

Files	Coverage Δ
...ugins/telemetryTable/components/TableComponent.vue	42.27% <25.00%> (+0.31%)	⬆️

... and 13 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3e31bbe...e4e3b7a. Read the comment docs.

[ozyx]

If the throttle gets us an easy, measurable performance improvement, great! What we can really benefit from though is a restructuring of the Vue components surrounding the TelemetryTable (which is no small order).

The elephant in the room is that we pass the row object all the way down to the TableCell, so Vue cannot selectively re-render elements that change. Instead, it has to re-render the entire list every time a single change is made (a single row added or removed). See this recording I made with Vue's debugger "highlight on update" feature:

Screen.Recording.2024-01-23.at.10.51.44.AM.mov

This is a pattern that plagues Open MCT performance in some of our most used and most complex areas of the code, so it's going to be a project.

In short: I'm OK with this as a quick perf boost, but long-term we should not throttle but just restructure the components and let Vue do the heavy lifting.

Lots of good information here

[akhenry]

If the throttle gets us an easy, measurable performance improvement, great! What we can really benefit from though is a restructuring of the Vue components surrounding the TelemetryTable (which is no small order).

The elephant in the room is that we pass the row object all the way down to the TableCell, so Vue cannot selectively re-render elements that change. Instead, it has to re-render the entire list every time a single change is made (a single row added or removed). See this recording I made with Vue's debugger "highlight on update" feature:
Screen.Recording.2024-01-23.at.10.51.44.AM.mov

This is a pattern that plagues Open MCT performance in some of our most used and most complex areas of the code, so it's going to be a project.

In short: I'm OK with this as a quick perf boost, but long-term we should not throttle but just restructure the components and let Vue do the heavy lifting.

Lots of good information here

I agree we should do the restructuring. I'm ok with keeping throttling long term as well, it's effectively batching updates and reducing the number of repaints which are always going to be costly.