Large Application, LabView seems to use only a single cpu core causing performance issues and process delays

[Yamaeda]

---

@David.Holst wrote:

that's interesting. If this is still true, this would explain, why the UI thread is burning. If one single bare property node within a case structure would shift the entire structure into thread synchronization, multiple of our state machines could end there.

---

Not any property node, but e.g. Value property switches to UI thread. I had a UI where i switched visibility of two big UI clusters on and off, and it took ~1s to switch! It was two free property visibility nodes and by simply wiring them together with an error wire to they became sequential it became practically instant!

So it seemed the UI tried to do it in parallell and probably by looping through all members (i don't know how it works under the hood) causing lots of conflicting updates and redraws. By doing it sequentially the conflicts were avoided.

[David.Holst]

Dear all,

I just want to follow up our discussion. We reworked our code and it seems we solved the major limitations.

Before reworking, the UI thread used one core in the range of 80-85%. Following steps were done:

• Clusters not visible within the UI (i.e. on another tab of the tab structure) are not updated any more and the main state machine as well as the "chart slaves" don't use bare property nodes any more within case structures.
  Result: approx 10% less CPU usage
• "Chart slaves", which are shown in separate subpanels, use DeferPanUpdts. Each slave has his own update period, which is user configurable. By maintaining the 10Hz update rate...
  Result: additionally approx 10% less CPU usage
• Reducing the update rate up to 3Hz showed an additional potential of reducing the CPU load by additionally 10%

Finally the CPU load of the UI thread is somewhere between 45% and 55%. In the end the test was done with 18 charts, each within its own subpanel, displaying 1 to 4 CHs per chart each. This is good enough to have a responsive GUI not showing lags or undefined loading times for pop-ups. Even UI thread intense tasks like building tree-controls, e.g. when using channel filtering, are fast enough. 

More potential could be in disabeling axis auto-update and user configurable plot layouts, but as long as the UI stays this responsive, we leave this user adaptable.

The data handling was not touched at all. We're writing each sample into the charts at 10Hz and the chart history is still 1024 elements. Just the UI panel update frequency was changed. Therefore data decimation etc. is, of course, still possible for further improvement. We kept (for now) the simple handling of more or less a "direct wire" between dequeue and chart.

Thank you all for your feedback. The result is a good mixture of the hints given within this discussion. Of course I'm not the thread opener, but from my point of view, the issue is solved.

All the best.
David

[billko]

That's some awesome refactoring that you did!

[mcduff]

This is an edge case, but it may be useful for your application.

We use laptops in the field, sometimes only with batteries and no backup. I do the following to limit UI updates and thus conserve power:

1. If the Window is minimized, do NOT update UI.
2. If the Screen becomes locked, do NOT update UI. Use a .NET callback for this one.

This is a bit more work, but you can "fake" your tabs with subpanels, and only open them is a user clicks the appropriate tab. (It also makes resizing much easier.) Below is a empty tab control that protrudes just above a splitter. The subpanel is below. When colored correctly it looks like a real tab control.

mcduff

Fake tab that is actually a subpanelWhen filled, looks like a real tab.

[richjoh]

OK, the issue is solved. The steps done to improve the UI thread is through the IDE. Do you plan on releasing a build?  Do you plan to use compile optimization?  There are ways to minimize the use of the UI through compiler optimization.  

Maybe too extreme but I thought I'd throw that out there.

[David.Holst]

Dear all,

just for all who are interested. I sanitized the GUI a bit, this way I can show at least a bit the layout and how we solved the scalability of the GUI. Its just one of two screens but the second one is more or less of the same kind. The picture is scaled down, but GUI is build for FullHD screens.

We kept the tab structure fixed size, as we use fixed size clusters to display the P&I diagrams which are used to control the setup. The other elements ensure, that the GUI is scalable enough.

@mcduff: Thanks for the hint of reducing UI updates further more, if window is not shown. Simple and effective, and we've not thought of this yet. Thanks.

@richjoh: Yes we want to release a build and we're definitely interested in minimizing UI usage through compiler optimization. Finally to know how it works and decide not to use is always better than not using because of not knowing 😉

All the best.

David