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

[Gubis]

How many channels are you updating live within the charts? Sometimes, changing something as small as the tickness of your plot lines can make the application quicker, which just shows how resource intensive UI updates in LV are... Can always try updating your indicators by index, which seems to be quicker a bit than other methods.

If you are using waveforms by chance, the chart history specifies not the number of samples to keep, but the number of waveforms. Which could mean that you are keeping more data in memory than you think you are. But this should only apply, if the application becomes slow after some time.

But as altenbach said, you will need to show your code to get a better answer.

[Michael_Munroe]

From everything discussed, I agree that your CPU is being consumed by the UI thread.  Your description leaves out a lot of significant details.

1.  How many signals are on each chart?

2.  How many points are on each chart?

3.  What is the chart history length set to?

4.  How many points are being received at 10Hz (100Hz?)

5.  Are all charts updated at the same time?

6.  Is the raw data displayed, or is it calibrated or filtered?

7.  Are any special fills or effects applied to the charts?

It is possible that your queue is not delaying your data, but the wiring between the dequeue and the chart is the problem.  Try optimizing that code, or wrap it in a subvi so it can be profiled. 

Maybe there are too many large buffer allocations for each update.  If your 550 samples are split into 12 charts, there may be some array optimization required.  Are there for loops used to decimate the data?

[MarvSchl]

@altenbach wrote:

---

@JÞB wrote:

Focusing in on the single core burning issue.  I would bet the UI Thread is chewing up that core! 

---

I was just about to say the same thing. What is the chart history length of all these charts? (550(!) channels in 12(!) charts at 100Hz(!)). The UI thread is single threaded and you are really hammering it. Everything else takes a backseat.

I don't think anyone can give more specific advice unless you show us some code.

---

@JÞB wrote:

Ok, I recalibrated my 8-Ball. 

Focusing in on the single core burning issue.  I would bet the UI Thread is chewing up that core!  Especially when you mention that you have charts updating in subpanel containers.  

TRY a judicious defer FP Updates here and there:) (can't see the whole picture,  use your experience to place the invoke nodes)

---

Thank you for your feedback and ideas. I think you are right, especially when it is single threaded. I also noticed a significant delay when triggering user events on the frontpanel, so the GUI thread seems to be the problem here. I guess I have a deadlock or something similar and the UI thread is slowing down other processes. That would explain the high single core usage. I found some information under this link ( https://zone.ni.com/reference/en-XX/help/371361P-01/lvconcepts/multitasking_in_labview/ )
and will make some further investigation in this direction.

@JÞB wrote:

---

---

Charts in subpanels (or tabs) or other containers like splitters, chew the UI thread for double bonus updates. .

---

I'm using all of them 🤔

regarding your questions:
Datarate and updaterate is 10Hz (not 100Hz as I have written in the starting post which I can't correct anymore). I'm running ~12 charts within subpanel container on up to two screens. Each chart can display only 2 channels, so only 24 channels (from a total of ~550) can be displayed in charts. Several channels are displayed as controls (in clusters representing piping and instrumentation diagrams (P&ID)). I'm also using dynamic events.

@Michael_Munroe wrote:

From everything discussed, I agree that your CPU is being consumed by the UI thread.  Your description leaves out a lot of significant details.

1.  How many signals are on each chart?

2.  How many points are on each chart?

3.  What is the chart history length set to?

4.  How many points are being received at 10Hz (100Hz?)

5.  Are all charts updated at the same time?

6.  Is the raw data displayed, or is it calibrated or filtered?

7.  Are any special fills or effects applied to the charts?

---

1. How many signals are on each chart?
- 0-2 Signals depending on user selection
2. How many points are on each chart?
- scalable depending on screen size
3. What is the chart history length set to?
- 1024
4. How many points are being received at 10Hz (100Hz?)
- 10 points per second per chart
5. Are all charts updated at the same time?
- yes
6. Is the raw data displayed, or is it calibrated or filtered?
- calibrated data
7. Are any special fills or effects applied to the charts?
- no

I have checked the following:
- Hyper threading in BIOS: is enabled and tested with a minimal example (which uses all cores with maximum CPU usage)
- Anti-virus or other security settings: seems to be ok
- The disk usage: seems to be ok

Further questions:

- Is there a way to multithread the GUI operations (for example: screen_01.vi and screen_02.vi are both independent VIs containing charts in subpanel containers. Is there a way to assign cpu cores one core handles all GUI operations of screen_01.vi and another core all operations of screen_02.vi)?

To my knowledge, it is not possible, because following the link "user interface — Handles the user interface. Behaves exactly the same in multi threaded applications as in single-threaded applications. VIs can run in the user interface thread, but the execution system alternates between cooperatively multitasking and responding to user interface events."

- Does LabVIEW handle event structures and especially dynamic events via UI thread?

cheers, Marvin

[altenbach]

---

@MarvSchl wrote:

- Is there a way to multithread the GUI operations (for example: screen_01.vi and screen_02.vi are both independent VIs containing charts in subpanel containers. Is there a way to assign cpu cores one core handles all GUI operations of screen_01.vi and another core all operations of screen_02.vi)?

---

You simply need to make sure that the user interface is reasonable and keep the data sent to the front panel limited to what the eye can actually follow (rate) and what the available pixels can actually display (resolution). All the data prep and decimation can easily be done in parallel threads. Keep the data on the diagram except what the user really needs to see. Keep the plots simple (single line thickness, no points, no fill, no grid) and turn off autoscaling for the axes as well as other "auto" settings (e.g. autoadjust scales)..

Also make sure that all events can complete quickly and that they don't lock the front panel until the event completes ("lock panel until event completes" is unfortunately the default setting).

Make sure no VIs are set to higher priority. For example "time critical" priority will severely neglect the UI thread in favor of computations, making the UI choppy and unresponsive. Don't mess with the default priorities!

Again, we haven't really seen any code yet and our advice is necessarily limited. I assume your code is clean and streamlined and that you don't shuffle massive data around via local/global variables and value property nodes (property nodes are very expensive because they are typically synchronous and require a thread switch). Keep arrays at fixed size to avoid expensive memory allocation calls, watch for allocation dots and think when branching wires.

[JÞB]

How many users are there?  That silly thing expects exactly 1 so, no, you aren't going to find a multicore GUI thread.  

You need a really smart user to process as much data as can be shoved down the single UI Thread.  Dumb it down to merely superhuman and the whole thing will be better. Better yet,  assume the user has the IQ of a lobotomized platypus and the attention span of a goldfish.   Then your users story will make sense. 

Did I challenge your thought process of what needs to be displayed yet?  Really,  rethink!

[David.Holst]

Dear all,

I'm working with MarvSchl on this topic and I would like to provide some add on informations and describe the circumstances...

Circumstances:

The setup is a larger test bench supervised by at least 2 persons in parallel. Of course just one person controls the UI, the second person supervises parameters of the setup (e.g. temperatures, pressures). Therefore multiple graphs etc. were requested. The setup will be used for different scientific investigations, that's why the user can/has to configure each chart the channels of his/her choice. The IQ of the user should be higher than average, but is expected to be level with a classical keyboard-monkey. GUI-VI is more or less free of not used/requested parameters (most is loaded from ini files). It's more a condition monitoring GUI than a "configure and set" type GUI.

Add on info:

Sample Code:
Unfortunatly, the code is under NDA and can't be uploaded and to complex to build a smaller example-case. I know it for myself, that helping without code is not the best. Therefore thank you all for your feedback. We definitely got some hints to check and to work with.

Regarding VIs and priorities:
Nothing was changed, as we know about the crude stuff that can happen, if some VIs were set to time critical, but thanks for the reminder

Data handling:

• data is centralized handled and the GUI-Graph consumers subscribe just for the data the user has selected. So just necessary data is sent by Qs (no globals or stuff like that).
• data is handled on single sample basis (data rate is 10 Hz). No arrays are built.

Things we will check now:

Seems we'll focus on reducing the UI thread load.

• as the GUI uses nested subpanels, splitter bars etc., we'll check if we can reduce loads with "defer FP update"
• reduce chart update rate by collecting samples and updating just twice a second
• doublecheck if GUI elements are updated but not shown, the number of charts can't be reduced (btw: these charts are distributed over 2 monitors, one VI per monitor)
• check if event structures have blocking code. I'm not expecting to find sth. as we use them just to enqueue a msg into the slave's Q. No real "working code" is within an event structure.

Thank you all for your fast and high quality feedback.

All the best,
David

[mcduff]

I have no idea is the following is still true, this is buried deep within the Genernal Error Handler VI that ships with LabVIEW. Do you have a lot of bare property nodes in case structures?

mcduff

[mcduff]

---

@David.Holst wrote:

•  

Things we will check now:

Seems we'll focus on reducing the UI thread load.

• as the GUI uses nested subpanels, splitter bars etc., we'll check if we can reduce loads with "defer FP update"
• reduce chart update rate by collecting samples and updating just twice a second
• doublecheck if GUI elements are updated but not shown, the number of charts can't be reduced (btw: these charts are distributed over 2 monitors, one VI per monitor)

All the best,
David

---

Below is with a simulated instrument, 3 channels at 10MSa/s, update every 100 ms.

Subpanel within a subpanel (The tabs are empty. A splitter below the tab to make it look like a tab. But really a subpanel.)

The plot is a subpanel within another subpanel. The tab is not real. A splitter is positioned right below the tab control where there is a subpanel. (Easier to scale things in a subpanel than tab).

Decimate data before displaying; graphs make copies of data. Make sure smooth updates and anti-aliasing is off for plots.10 Hz should be no problem; I would look elsewhere in your code.

Check for overlapping GUI elements; for some reason they can make LabVIEW slow to a crawl,

mcduff

[Yamaeda]

Someone already mentioned Defer Panel updates, but when updating several graphs and such, it might be a good idea to Defer, update all, then turn it back on, that way you should only get 1 redraw (technically 2) instead of 1 per update.

[David.Holst]

Hi myduff,

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.

That's another point on our list of things to try. Thanks a lot.

David