Updating heavy populated UI

[_Y_]

There is a LabVIEW program with an extensive output to UI (LabVIEW 2011, Linux). The UI consists of three full-screens VIs that are visible in three monitors of the computer. Each VI displays multiple plots and other UI objects.

The program cannot update all three screens with required rate. Even more, the internal calculation processes are also slow. However, if one or two of these UI VIs are not visible (minimised), the program works as it must. So, updating the UI is the bottleneck.

By the way, monitoring of the processors: only one processor is fully (almost) loaded at each moment. Two processors out of four are usually almost non-loaded. Load is moved between processors (randomly?).

Have someone experience with such a problem? What could be a strategy to solve it?

Thank you.

[perhult]

What is the required rate of update?

Do you change the properties of controls (for instance set the background color of a numeric control to red) programmatically? This could be time consuming.

Also what types of plots are you using how are you processing the data for them?

You could try to profile your application to see what is slowing down the program.

Also, you could post your VIs here if you want someone else to look at it.

[Mark_Yedinak]

What is your application's architecture? Have you separated the UI tasks from the processing tasks? I suspect your performance issues are code related and not a LabVIEW issue. For example, if you have one VI that takes time to complete and call it in multiple parallel loops if this VI is not reentrsnt and set to preload you will create a bottleneck in your system. Even with parallel tasks only one will be able to use this VI at one time.

[_Y_]

Thank you for the replies. Unfortunately, the problem is not so simple. The short answers are:

1. Yes, properties of some controls are updated usung refs. Unfoirtunately it is unavoidable. I am thinking how to reduce frequency of such updates but it is not so frequent anyhow.

2. XY plots and they are many.

3. Yes, of course, I did the profiling. There is no obvious bottleneck.

4. Unfortunatlely, posting the code here is out of considerations. It contains approx 1500 VIs and it belongs to the customer.

5. The architecture is based on asinchronous processes and extensively uses reentrant VIs.

As you see, I already searched throug most obvious things. This is why do I ask about the strategy. So far I foresee only the way for small improvements: saving one millisec here and a half there. Not a promising approach:( My main hope is geting an advice on more even distribution of the work between processors.

[M_Peeker]

My first guess would be to blame the property nodes anyway, not because they are updated extensively but because they are there. Any code that contains a property node to a front panel object is forced to run in the user interface thread, hence limiting the possibilities of multithreading. If you can get the property nodes out of your asynchronous processes that might help, simple test would be to use diagram disable across these.

[Mark_Yedinak]

I would recommend you create a dedicated task, or possibly three (one for each graph) to handle the UI. Don't use any property nodes in your processing tasks. Pass the data to be displayed using queues. Also, evaluate if you really need to display everything. You may be able to display the complete data set. You may be able to display less. A human will probably not tell the difference if display 1000 data points in 1 second versus 100000.

[JÞB]

One thing that can really speed up the updates is using the defer front panel updates method.  calling this method causes all pending UI updates to complete, then all new updates are placed in the pending queue without causeing the UI thread switch for each FP update, setting th DFP method back to False allows the FP objects to be updated with one switch to the UI thread.

Additionally, ensure none of the FP objects overlap in total bounds (the rectangle than contains every part of the object encluding labels and captions) if any part of an object overlaps another BOTH must be refreshed when either one is updated and this can seriously chew up processors.  I once saw a UI where the developer took all the lables and moved them off screen to some other area (For "Storage" of course,) this made EVERY obejct overlap every other object. (I explained to him that there were better ways to do it) needless to say the performance improvement was amazing when I removed the undesired lables.

Lastly look into using subpanels for controls that are updated frequently via VI server refs by converting them to GERMs. This nugget discusses how the approach was investigated by Richard Sorrellis (AKA Broken Arrow) and myself and some of the perfomance improvements he was able to achieve.